views:

3642

answers:

2

What are the steps to get Team Foundation Server running unit tests when a given build runs?

What are the caveats / pitfalls / workarounds a dev or sysadmin should be aware of when setting up a TFS server to do this for the first time?

What are common troubleshooting steps for unit test problems during builds?

+7  A: 

it depends on which version of TFS you are running, so I will assume it is 2008.

Firstly, you must have Team Edition for Testers installed on the computer that will act as your build agent, as stated in How To: Create a Build Definition

There are a couple of ways to tell Team Build to run tests for your build.

  1. Unit tests can be run from a defined Test List within the Solution being built. This list is referenced by the build definition and all tests within the chosen list(s) are executed. More info here
  2. WildCard test exectution is also available by defining a wildcard mask (i.e. Test*.dll) that instructs Team Build to run any tests present in assemblies that match the mask. This is done when defining the build definition as well.

Things to note:

If you intend to use the wildcard method and want to enable code coverage for your test configuration, you must add the following to your build definition file to enable it.

<RunConfigFile>$(SolutionRoot)\TestRunConfig.testrunconfig</RunConfigFile>

See my previous question on this for more info here

Mr. Kraus
+3  A: 

If you don't want to use test configs (A Pain in the ass to manage) just run all the test in a .dll by adding this to the build config:

<ItemGroup>
    <TestContainerInOutput Include="MyProject.UnitTests.dll" />
</ItemGroup>

The whole process is smooth and fairly simple. You can inspect the unit tests that filaed on the build server by opening the test result file locally (a bit of a pain) but generally you'll just run the unit tests locally and you can see the results immediately.

If you are used to NUnit, you may opt to sort the tests by classname, it gives a similar view.

Careful with code coverage, it makes complete copies of your binaries on compile. If your binaries are sufficiently large and you compile often, it will eat through drive space quickly.

vfilby
But the wildcard method does allow you to run all tests from different test projects. Imagine the list of <TestContainerInOutput when you have 100 different test projects.
Ola