运行单元测试后避免完整的解决方案构建

Question

I'm working with Unit Test using VS2013 Professional. In particular I'm using the NUnit framework (NUnit TestAdapter for VS2013). My problem is that when I run my tests then VS starts building all the projects inside the solution. Currently the Unit Test project does not reference any solution project.

If I simply code a single test method like:

[Test]
public void SimpleTestMethod(){
    Assert.That("a", Is.EqualTo("a"));
}

and the Unit Test project is in a Solution with N project, when I run my test then VS will build all N-1 project... In my case this behavior is boring because it takes too much time (the solution contains many projects) and some projects contain errors.

Is there a way to run my SimpleTestMethod() without complete solution building?

Answer 1

Break your test project to multiple projects that only reference a subset of the solution's projects.

This is also good test housekeeping - have a separate unit test project for each solution project instead of one huge project with dependencies to anything else. There are several advantages to this:

• Tests run faster
• It's a lot easier to isolate test cases, especially configuration settings
• You can version projects and their test cases together

A good naming practice is to name your test projects the same as their target projects with a .Tests suffix. You can also create a solution folder (not a real folder) called "Tests" and move the test projects in it.

As for the why: Test runners use the Unit Test assembly and its dependencies to run their tests. If any of the assembly's dependencies change, the assembly and the dependencies have to be rebuilt. Visual Studio doesn't know what the external tool will call so it has to build all changed assemblies and their dependents.

If the build fails, there are no valid assemblies for the test runner to use so VS has to rebuild the entire solution before the runner can work. In this case, the obvious solution is to fix the error.

There are some stopgap options you can use until you can fix the error:

• Temporarily remove the broken project from the build configuration
• Split the solution so that you have a solution that can be built and tested

Answer 2

I struggled with this for a very long time as well. I actually hated the automatic build process, even when everything was successful.

I started to run tests through the command line. No build process is necessary. You can write your own .bat files and keep logs of test results. There are plenty of command line parameters that can be added to customize for what you are looking for.

https://msdn.microsoft.com/en-us/library/jj155796.aspx