How to Diagnose a Test Failure on TeamCity

Have you ever had that unit test that works locally, but fails on team city. Turns out you can debug them and find out that it isn’t team city’s fault.

Failing Team City Builds

You run the test locally, pass, run them on team city, fail. Alright, time to get serious, 1, pull the TeamCity artifact down locally, 2, run MSTest from command line like TeamCity does, 3, start debugging. Most unit test frameworks throw exceptions when a test fails, great way to debug into the test.

Make sure you have an artifact from TeamCity or you can’t pull down the test. Well, unless you are an admin on the box.

TeamCity Test Artifact

TeamCity Download Artifact

Visual Studio Attach to Process

Open up Visual Studio Command Prompt for VS2015.

mstest /testcontainer:MyTests.dll

Next, attach to the MSTest process QUICKLY. MSTest launches QTAgent32.exe for running the actual unit tests but it won’t stop to wait for you.

Attach To Process QTAgent32.exe

In the end, it turned out another test ran first, and our second tests couldn’t set a private static readonly because of its if null check.

[code langauge=”csharp”]
private static readonly List<int> Codes = new List<int>();

Benchmarking MVC6 Beta 8

I have always been curious how fast MVC can be, and a previous article ( detailed the Web API  speeds with IIS 7.5 to IIS 8 along with self-hosted options. So I spun up a MVC 6 web  app with Beta-8 and used the Apache BenchMark to test it out. Running a i7-3740QM CPU with Windows 7.

My controller contained only this,


public class ValuesController : Controller
// GET: api/values
public IEnumerable<string> Get()
return new string[] { "value1", "value2" };


I fired up Apache Benchmark using the command below.

[code]ab -n 1000 -c 2 http://localhost:5000/api/Values [/code]

3.064MS! It beats out the 17.818 from Windows 8 Self Host and I am running Windows 7! This is a localhost call, so adding in SSL or a network would likely increase this. but it helps if it starts really low first.

The first “Time per request” is for each request * concurrent request number. The second “Time per request” is the actual individual requests. Wonderfully explained at this ServerFault question


For giggles, I pumped it up to 10,000 concurrent requests, I also tried 5,000 concurrent requests and got the same ~7ms response time.


So basically MVC6 is FAST! VS2015 diagnostic session for those who wanted to take a peek. I might have had around 100 chrome tabs open when running this benchmark.



vs2015 diagnostic session