Question

I’ve researched a few questions questions here on a preferred directory structure for unit testing and it seems to be personal preference. Most responses fall into seperate test projects within the project foler (MyProject and MyProject\UnitTest), or a mirrored directory structure with a UnitTest top level folder. I’m wondering if TFS is geared to more easily use one methodology over the other and the pros and cons of each (specifically, TFS 2010). Access to references seems to be the biggest concern to me; is this naive? What are some other major considerations when creating a unit testing environment?

Answer 1

First off, it makes sense to put unit tests in a separate assembly from the actual code being tested. I know this is probably obvious, but I want to call it out so there is no confusion when you talk of putting tests in the same folder as the project. You don’t want your unit tests in your deployed, production code, so they need to be in a separate assembly. So I recommend a separate unit test project that compiles into a separate assembly. This is consistent with Microsoft guidance and examples.

The simplest option is to create a unit test project that has project references to the other projects you want to test. This will ensure that all assemblies that those projects reference will be accessible to the unit tests. Visual Studio can access tests in many different structures, but if you are running a build via TFS and executing tests as part of the build, you need to ensure that the build server will be able to resolve all the references in all your projects–not just the unit test project. One good way to do this is to create a “reference library” folder for your solution and copy any 3rd party DLLs you intend to reference there (be sure to add those files to the solution even though nothing is using them yet).

After the DLLs are copied to that folder and added to the solution, you should add references to the DLLs from that same folder. Then, when you run a build on the build server the DLLs will always be found in the same relative path on the build server as they were found on your own machine when you added the reference in the first place. The references are stored in projects with relative paths, so it makes it so future developers (and the build machine) will be able to resolve the references and won’t get those broken reference issues when they access the code and attempt to compile it for the first time.

I like to create a single unit test project for my solution, then within that unit test project, create a separate folder (potentially a separate namespace) for each of the projects that I am testing. For example, if my solution has a BusinessLogic project and a Helper project–both of which contain code I want to unit test–I would have a single unit test project that contained two folders: BusinessLogic and Helpers. The tests for each project would be grouped into the appropriate folder.