One of the things i always try to impress upon business is the need for a dashboards, and TFS provides a great interface for this. We use them to report on our manual testing, and we were looking at also using them to report on test automation.

I’ve seen CodedUI test results in the past update the test from links to test automation via test manager. I thought we might be able to use this but its pretty hard, instead I just used the TFS Client (old one, not the new REST client unfortunately, will revise code in another post). Below is the final outcome I wanted to end up with on Out dashboard:

The concept is pretty straight forward, we wanted to achieve something like the following with our NUnit units Tests:

[Test]
[TfsTestCase(65871)]
public void MyUnitTestMethod()
{
// Test stuff here
}

So we could simply add an attribute to the Unit test with the ID of the test case and the library would take care of the rest. And its “almost” that easy.

In order to log test results you also need to Test Suite ID and the Test Plan ID from TFS, and we need to initialize the run at the start, then close it at the end so we end up with all of our units tests in the same run (I’ve done one run per fixture but you could change this).

So in the library there is two static int that need to be set and I also created a “Test Rig” class that I inherit my test Fixtures from that have the appropriate OneTimeSetup and OneTimeTearDown methods to start the test run, then close it off.

There is also some static variables for caching all the test results and adding them in one go at the end (I couldn’t work out how to add them as they are running).

The end result is something like the below:

[TestFixture]
class MyTestClass : ControllerTestRig
{
public MyTestClass () //ctor for setting static vars, runs before OneTimeSetup
{
NUnitTfsTestCase.TfsService.RunData.TestPlanId = 65213;
NUnitTfsTestCase.TfsService.RunData.TestSuiteId = 65275;
}

[Test]
[TfsTestCase(65871)]
public void MyUnitTestMethod()
{
// Test stuff here
}
}

It’s important to note at this stage that this library assumes that your Build Agent has authentication with your TFS server. In our first case for this we are using on-premise TFS and a Build Agent that is running under a domain windows user account with the correct permissions. I will do an update later for different auth methods, and also do an example for VSTS (Formally VSO), as I am going to move this over to a VSTS hosted project in the next few weeks.

Also you need to put the following app settings in for the library to pick up your TFS server address and project name

<add key="tpcUri" value="https://mytfsserver.com.au/tfs/DefaultCollection" />
<add key="teamProjectName" value="MyProjectName" />

Once the above is done we now get a nice test run for each Test Fixture in our Test library, as well as the test cases having their status get updated.

Any test that error it will pass on the error status and also the message. We are using NUnit 3 for this, because 2.x isn’t under active development and doesn’t provide a lot of detail in the TestContext for use to log to TFS.

The source code is available on GitHub here and the nuget package is available on nuget.org. Feel free to send a PR if you want to change or fix something!