Making Separate Assemblies For Different Types Of Tests For The Same Component?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.