Organizing Unit Tests in Visual Studio

I am currently creating a paired assembly unit test for each assembly in my project, both located in the same folder.

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

Looking at open source projects, I saw how some smaller project put all the tests in one assembly, while others divided it, like mine. I am dealing with a big solution, so it would be pretty crazy to put all the tests in one project.

I currently have msbuild logic to run tests in all * .Test.csproj files. If I had all my tests in a different folder, I would not need to do this.

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

thanks

+4
source share
4 answers

I am doing the same, but I am changing the default namespace for each test project to match the namespace of the production project. Thus, the tests for the XYFoo class are in XYFooTest , not XYTest.FooTest - this means that you need to use less directives and, as a rule, simplifies the process.

My main reason we want to keep these two in separate projects is to avoid either including tests in the production library or sending an unverified library. With a separate project structure, you can run unit tests against everything you build. It also makes it easier to view only production classes that do not have twice as many files to view (when you get the "feel" of the library).

Finally, do not forget that if you need to access internal members when testing, always [InternalsVisibleTo] .

+4
source

I suggest making as few unit test projects as possible. The reason is that every one you create adds at least ten seconds of compilation time. In a large project, he begins to take shape.

The directory structure is used here:

Projectname / branches / trunk / projects / code / codeproject1
Projectname / branches / trunk / projects / code / codeproject2
Projectname / branches / trunk / projects / code / codeproject3
Projectname / branches / trunk / projects / Tests / testproject1
Projectname / branches / trunk / Projectname dependencies / prototypes
Projectname / ...

and inside testproject1, the following directory structure:

codeproject1 /
codeproject2 /
codeproject2 / web
codeproject2 / web / MVC
codeproject3 /
codeproject3 / support

+3
source

I am doing the same thing, except that each project is in its own folder in the same root folder. Something like the following:

Folder for solution

  • ProjectA folder
  • ProjectA.Test folder
  • ProjectB folder
  • ProjectB.Test folder
+2
source

I always have a separate test project for each project. In part, I like the organization of this, but I also often encounter situations where I decided to split the library into my own solution so that it could be reused with other solutions. In cases where the library project has a separate test project (and not all tests in one project), greatly simplify this library.

+1
source

All Articles