Intro To Unit Testing: 2 of n

Where do tests fit into my project and process?

There are a few ways to structure unit tests. Two of the most common seem to be one to one assemblies and same assembly. One to one assemblies meaning one test assembly for each assembly being tested. This approach has the benefit of easily removing the test assemblies before releasing code to production. It also allows testing release built code with out an extra build cycle like the following method requires. One drawback is that internal classes are harder to test.

The second structure, same assembly, has the TestFixtures in the assembly being tested. The main challenge with this is creating builds without the tests. I’ve seen this handled two way, first by the build script excluding all files under a Tests directory. And secondly, using compiler directives like #if TEST around the test code. Both have draws backs but the main one being two complies one to test and one to release. The main advantages are access to internal classes and fewer assemblies in a solution.

Which is right? As with many things, it depends.

Unit tests generally fit into the development in two key places, three for TDD. The first is before any code check-in the unit tests should be run and pass. Secondly, the continuous integration system should run the tests and fail the build if the tests fail. Third, if developing using TDD you would run the tests almost constantly while developing and refactoring.