Question

I’m currently creating a paired unit test assembly for every assembly in my project, both are in the same folder.

• MyProject/MyProject.csproj
• MyProject.Test/MyProject.Test.csproj

Looking at open source projects, I’ve seen some smaller project put all tests in one assembly, and other split it out like mine. I’m dealing with a large solution so it would be pretty crazy to put all tests in one project.

I currently have msbuild logic to run tests on all *.Test.csproj files. If I had all my tests in a different folder I wouldn’t need to do this.

Just wondering if there are any good arguments to do things a certain way.

Thanks

Answer 1

I do it the same way but I change the default namespace for each test project to match the namespace of the production project. So the tests for class X.Y.Foo are in X.Y.FooTest rather than X.Y.Test.FooTest – it means you need fewer using directives, and generally makes things simpler.

My main reason for wanting to keep the two in separate projects is to avoid either including the tests in the production library or having to ship an untested library. With the separate project structure, you can run unit tests against anything you build. It also makes it easier to look through just the production classes without having twice as many files to look at (when getting the “feel” of a library).

Finally, don’t forget that if you need to access internal members when testing, there’s always [InternalsVisibleTo].