Write Unit tests into an assembly or in a separate assembly?

Question

When writing unit tests, do you place your tests inside the assembly you wish to test or in a separate test assembly? I have written an application with the tests in classes in a separate assembly for ease of deloyment as I can just exclude the assembly. Does anyone write there tests within the assembly you wish to test and if so what is the justification for it?

Answer 1

I have a single solution with an interface project, a tests project, a domain project and a data project. When i release i just publish the interface, which doesnt reference Tests so it doesnt get compiled in.

Edit: The bottom line is really that you dont want it to be part of your final release. You can achieve this automatically in VS by using a separate project/assembly. However you can have it in the same assembly, but then just not compile that code if you're using nant or msbuild. Bit messy though, keep things tidy, use a separate assembly :)

Answer 2

In a different assembly. Otherwise your assembly will reference the test framework (eg Nunit.Framework.dll) and you'll need to install it on the customer machine,

Even if what you ship is a library, and you want your customer to see the unit tests as an example or a specificiation on how to use the objects you provide, there is very little advantage in including in the production assembly.

Answer 3

This is widely debated all over the net.

We use separate assemblies and the InternalsVisibleTo attribute to help the tester assemblies see all the innards of the tested assemblies. We tend to make one test assembly for each assembly we're testing.

Answer 4

I'd say that the only time you want to incorporate any test code in your final deployment is when the test code is there for monitoring and control of the application.

Leaving the test code in the deployment:

• bloats the code to no real advantage at all - all that extra code tagging along that isn't going to be used at all in situ.
• affects releases - do you release a new version of the complete app. when what you've improved is only in the test code, e.g. a test suite is extended as a result of a bug fix.
• you can't easily reuse the test framework on another project - if you are always releasing app's that are clogged with test code, any subsequent projects have to reuse the same test code. Otherwise, you finish up with the situation where app A is using v1.2 of the test platform for those aspects of the app. that are common across all your app's, e.g. a presentation layer, or a business logic framework, etc. And app. B is using v1.1 of the test framework, app. C is using v1.2.1, etc.

Decoupling on the otherhand allows you to:

• easily upgrade and extend the test suite as required.
• easily reuse the test suite across multiple projects.
• use a common test framework across multiple projects.

HTH

cheers,

Rob

Answer 5

You can keep them in separate assemblies in the solution, and ILMerge them later for debugging, and don't ILMerge them for release.