I was told by a few members here that splitting up my unit tests into different assemblies for different components is the best way to structure unit tests. Now, I have a few questions about that idea.

  1. What are the advantages of this? Organization, and isolation of errors?
  2. Let's say I have a component named "calculator", and I create an assembly for the unit tests on "calculator". Would I create a separate assembly for the integration tests I want to run on "calculator"? Or is the definition of an integration test a test across multiple components, like "calculator" and whatever else, which would require a separate assembly to test both of them together? In that case, would I have one assembly to do all of the integration testing for every component combination?

3 Answers 3


This could be a weird semantic thing, but it sounds like you're equating "component" to "class". I would normally associate "component" with "assembly".

In other words, one unit test assembly per assembly-under-test. That's a pretty common configuration in my experience. You do that in order to minimize the number of dependencies your tests have. Ideally they should only depend on the specific assembly being tested, but even in the worst case scenario, they'll still only depend on indirect dependencies of the AUT.

Integration testing is a whole other animal; you'd normally want that to be totally segregated from your unit tests, since an integration test will have all kinds of dependencies folded in from various parts of the application (that's why it's called an integration test...). Keep those far, far away from your unit tests, otherwise you'll find yourself trying to manage build errors and unit test failures at the same time. Not fun.

  • I am working with a large single-assembly system, and was given the recommendation to create a multi-assembly unit testing system. This is why I'm having trouble deciding where to draw the boundaries between my test assemblies. What do you recommend in my situation?
    – sooprise
    Jun 1, 2011 at 13:15
  • @sooprise: The term "large single-assembly system" strikes fear into the heart of any experienced .NET developer. The very first thing I would work on is sorting out the mess of dependencies that will inevitably exist in the application assembly. Do this one assembly at a time, i.e. start by refactoring all the "calculator" related classes into a "calculator" assembly, replacing concrete classes with interfaces and constructor calls with dependency injection wherever you need to break a dependency. Then, write unit tests for each system assembly in a corresponding unit test assembly.
    – Aaronaught
    Jun 1, 2011 at 13:46

if you need to run the tests separately - say unit tests on every build, integration tests once per day - then this might be useful

or if the test assemblies are getting too big to easily find things in them

otherwise i don't see the point

  • As far as the "unit tests on every build, integration tests once per day", can this be accomplished using one assembly and multiple NUnit test categories? I'm still having trouble deciding which route to take.
    – sooprise
    Jun 6, 2011 at 14:24
  • @sooprise: it doesn't matter. Pick one and get moving. If it turns out to be inconvenient later, refactor the tests. ;-) Jun 6, 2011 at 16:44

Answer to a similar question:

In my opinion, unit tests should be placed in a separate assembly from production code. Here are just a few cons of placing unit tests in the same assembly or assemblies as production code are:

Unit tests get shipped with production code. The only thing shipped with product code is production code. Assemblies will be unnecessarily bloated by unit tests. Unit tests can affect build processes like automated or continuous build. I don't really know of any pros. Having an extra project (or 10) isn't a con.

Edit: More Info On Build and Shipping

I would further recommend that any automated build process place production and unit tests into different locations. Ideally, the unit test build process only runs if the production code builds, and copies the product files into the unit tests directory. Doing it this way results in the actual bits being separated for shipping, etc. Additionally, it is fairly trivial to run automated unit testing at this point on all tests in a particular directory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.