CODEWITHSUNDEEP
c#unit-testing
anonym0use
anonym0use

Reputation: 3046

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

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?

Upvotes: 20

Views: 3405

Answers (5)

Andrew Bullock
Andrew Bullock

Reputation: 37378

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 doesn't reference Tests so it doesn't get compiled in.

Edit: The bottom line is really that you don't 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 :)

Upvotes: 11

dviljoen
dviljoen

Reputation: 1632

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

Upvotes: 0

Rob Wells
Rob Wells

Reputation: 37103

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

Upvotes: 10

Stephan Leclercq
Stephan Leclercq

Reputation: 893

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.

Upvotes: 5

Will Dean
Will Dean

Reputation: 39500

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.

Upvotes: 11

Related Questions