单元测试代码的最佳位置

Question

I have a multi-project solution which I wish to apply unit testing to. The project is well encapsulated and most of the unit tests will use classes only from within the project they are testing.

I also have a number of integration test cases which test the interaction of multiple projects.

Obviously I can just throw all the test code together in a separate project but I am cautious about the idea of creating a Great Project that has dependencies through the entire solution.

Is it better to create a private class for unit tests in each project and have a separate project for integration testing? Or is there no appreciable architectural benefit?

Answer 1

You should be putting the unit tests into a separate assembly. By doing this you can ensure that they are not part of any released product.

If you adopt a convention where the test projects have the word Test in their name then it is a simple matter to do a wild card deletion on your final build output to ensure that you're not shipping test assemblies.

I am cautious about the idea of creating a Great Project that has dependencies through the entire solution

As your solution grows in size you can split your tests up in to assemblies that target specific areas of your application - you can start with a monolithic test assembly then split it up when it makes sense to.

Answer 2

Having experience with working with a solution that has about 110 projects including unit test projects, I may have have something to add

• Having many little projects will increase your build time versus having larger projects. Depending on the size and complexity of your compilation, this might be something you're worried about.

One implementation I worked with used a project structure something like this:

- CompanyName.Feature
- CompanyName.Fetaure.Test.Unit
- CompanyName.Feature.Test.Integration
- CompanyName.Feature.Test.Load
- etc...

This level of granularity is an improvement compared to a monolithic test project; however, I feel like there is a better way

Instead of breaking out all the test, instead, make sure that you test on a feature by feature basis. At that point I would be comfortable actually having my unit and integration tests in the same project mapped out to different folders. Ideally something like this:

 - CompanyName.Feature
 - CompanyName.Feature.Test
      \Unit
      \Integration
      \Load
      \etc...

1. Assuming your codebase isn't currently suffering from some issues with circular dependencies, this should also minimize the references that span across the code base.
2. This also has the benefit where if you write any code that assists in testing (ie: generation of test data) , you can share it between your unit and integration tests.