Should Test Code be Separate from Source/Production Code

Question

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

Answer 1

Yes, they should be separate (folders and preferably projects). Some reasons:

• GREP. Searching for a string in production source is easier.
• Code coverage. Imagine trying to specify which files to include for coverage.
• Different standards. You may want to run static analysis, etc. only on production code.
• Simplified makefiles/build scripts.

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.

Answer 2

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).

Same project approach

• References/external libraries dependencies: unit testing and mocking frameworks usually come with few dependencies on it's own, combine that with libraries you need for actual project and list grows very quickly (and nobody likes huge lists, right?)
• Naming collisions: having class named 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)
• overall feeling of ubiquitous mess

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.

Separated approach

• Projects number: you'll have to count the number of libraries you produce twice. Once for project code alone, another time for tests. When bigger projects are involved (200-300+ sub-projects/libraries) having that number doubled by test projects extends IDE startup time in a way you never want to experience

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.