Reputation: 9785
Even if we have a Makefile or something similar to separate the test code when shipping product. In my opinion, they should be separate, but i am not entirely convinced as to WHY
Upvotes: 13
Views: 4619
Reputation: 3297
In fully automated building and unit testing framework, you can essentially separate them out.
It makes more sense to fire up the automated unit tests after the nightly build is done. Keeping them separate makes it easier for maintenance purposes.
Upvotes: 1
Reputation: 31484
Since I had a chance to work with both approaches (separated and with project code), here's few tiny-things that were getting in a way to note (C#, Visual Studio, MsBuild).
MyClass
, common approach is to name test class MyClassTest
- this causes tiny annoyances when using navigation/naming completition tools (since there's bigger chance you'll have more than one result to chose from for quick navigation)Naming collisions can actually get even more tiresome, considering how classes relating to similar functionality usually share prefix (eg. ListManager
... Converter, Formatter, Provider). Navigating between comprehensible number of items (usually 3-7) is not a problem - enter tests, enter long lists again.
Of course, modern machines will mitigate projects number issue. Unless this really becomes a problem, I'd always go for separated projects approach - it's just more neat and clean and way easier to manage.
Upvotes: 5
Reputation: 25573
Yes, they should be separate (folders and preferably projects). Some reasons:
Modern IDEs will allow you to work on code from separate projects/folders as if they were adjacent.
The worst thing you can do is to include test and production code in the same file (with conditional compilation, different entry points, etc.). Not only can this confuse developers trying to read the code, you always run the risk of accidentally shipping test code.
Upvotes: 11