NuGet Package Restore and Unit Test filtering in TFS Build Online

In a previous post I blogged about how to set up a project so that the NuGet packages aren't added to source control. This post is a sort-of sequel to that one, looking at basic steps in getting the same project building in TFS Build and having its unit tests run by TFS Build. In my case I'm using TFS Build Online, but the steps should be pretty similar in an on premise installation of TFS Build.

We're aiming to end up with this:

This is what we do:

1. Create a new Build Definition using an appropriate build process file

New Build Definitions are created in Visual Studio 2013 in Team Explorer, Builds, click on the "New Build Definition" link.

You are shown a tabbed properties sheet. Most of the tabs are fairly self explanatory but the most complicated one is the "Process" tab. The "Build process file" which you select at the top, controls which "Build process parameters" you are shown at the bottom.

The key here is that we need to select a build process file that will restore NuGet packages before building as we are not checking our NuGet packages into TFS. The default build process file in my version of TFS is "DefaultTemplate.11.1.xaml"; this will not restore NuGet packages so it's no good for our purposes. In TFS Build Online there is a build process file called "TfvcTemplate.12.xaml" available which does restore NuGet packages before build, so I use this.

(In the end the build process file is simply a WF 4 workflow; if you want to you can customise it and even add WF activities that you have defined yourself)

2. Specify the solution(s) to build and unit test filters

This is where we set the Build process parameters:

In the "2.Build" section set the solutions to build as shown above.

Now, the test filters.  You may not want to use test filters of course, you may want to run all your unit tests. In my case I have an Azure Cloud Services application that uses Azure table storage for most of the backing storage. I therefore have (roughly) three kinds of unit tests:

1. Tests that test the repository layer and therefore need a running Azure Storage Emulator to work.
2. Tests that have some kind of dependency upon the environment being configured in a certain way (in production this is achieved by using Cloud Services Startup tasks).
3. Tests that use a mock implementation for the repository layer and do not have any dependency on the environment other than using file system directories available through the TestContext object.

Tests of types (1) and (2) will always fail if run by TFS Build; how do I tell TFS Build that I only want to run tests of type (3)?  Answer: using the Test case filter property in my build process parameters (if you're using a different build process file the property may be called something different, but it will almost certainly be there somewhere). I indicate the tests that are of type (1) or (2) by decorating them with TestCategory attributes, as shown below:

        [TestMethod, TestCategory("RequiresStorage")]
        public void CreateAndRetrieveUser()

I give tests of type (1) a TestCategory of "RequiresStorage" and tests of type (2) a TestCategory of "RequiresInfrastructure". Then I set the Test case filter to:

TestCategory!=RequiresStorage&TestCategory!=RequiresInfrastructure

as shown above.  That's all!