Best practices: Unit Test structuring

Question

I'm a bit confused. Got project which is covered by unit tests in different assembly. Co-developer created another project + another unit test assembly too. Now we want to mix some logic between both unit test projects (object factories, some initialization tasks, injection/mocking helpers, etc.). That would cause his project to reference assemblies mine uses.

I found a viewpoint which stands for 1 unit test assembly for all project (sometimes 2, where 2nd contains integration tests). Is this the right way? If not - where to put that shared logic for unit tests?

Answer 1

The rationale why you should put unit tests in a seperate assemblies is to prevent mixing up test code with production code. Assemblies provide a clean seperation of concerns and makes it flexible enough for you to remove the tests when they're not needed. E.g. when you release, the end-customer is not interested in downloading all test code when he/she only wants to use the end result.

Regarding having many test assemblies (one for each "actual code" assembly) is a sane idea. Adding references between test assemblies isn't that difficult and actually helps you to avoid mixing up code too much, since you don't want a lot of references (i.e. dependencies) between assemblies.

Also don't try to have too much shared logic for unit tests because that's what unit test/mocking/DI frameworks are for! Having many custom-implemented factories in your test code is a good indicator that you have made the production code way too complicated than what it needs to be.

Answer 2

There are certainly different approaches, there is no single "right way". This is how we structured our tests:

We have "modules" in our product, which consist of several assemblies. For each "module" we have one single unit test assembly, and one single integration test assembly. We are referencing test assemblies from others this way:

• "core" unit tests do not reference anything. It contains also helper classes for unit tests.
• "core" integration tests reference "core" unit tests. It contains additional integration tests helper classes (eg. database stuff)
• "module X" unit tests reference "core" unit tests
• "module X" integration tests could reference "module X" unit tests and "core" tests

"module X" tests of course never reference "module Y" tests.