Shortly after learning about the great performance profiling tools built into Visual Studio 2015 (we've just upgraded from 2010, when the best free solution was to use SlimTune [which is awesome for a free, unsupported, open-source tool, but not as awesome as the tools in VS 2015]), I wanted to be able to performance profile slow running unit tests.
Previously, using the afore mentioned SlimTune (https://code.google.com/archive/p/slimtune/), I would run the NUnit gui runner and run the test I was interested in. Although this is still an option using the new VS tools, it doesn't give you a very accurate picture of what's taking the time and, importantly, results in the "hot path" analysis not being useful.
As such, I followed these simple steps to profile my first few tests.
Nothing special here, I just marked the test for profiling with a unique category so I could pull it out and run it independently from the command line:
[Test]
[Category("Profile-Me")
public void SlowRunningTest_ShouldRunFaster()
{
Thread.Sleep(1000);
}
Next, I fired up the performance profiler from within Visual Studio using:
Debug -> Start Diagnostic Tools without Debugging...
Then:
- Change the Target to executable & click Start;
- Choose the type of profiling you're after:
- Instrumentation won't work here, because you're not profiling an assembly you've built with profiling in;
- I generally go with CPU sampling, because this gives you a pretty good idea what's taking the time in your offending test.
- On the next screen, you need to choose the executable option again;
- Then you need to specify some options for the executable:
- The file path will be the path to your installation of the NUnit console runner;
- The command line arguments should point the console runner to your assembly or NUnit project, and specifically include your special profiling category.
- e.g.
C:\Path\To\Tests\MyTestProj.nunit /include: Profile-Me
From here its easy: just finish the wizard to run the test. Once the test completes, VS will compile a performance report which can be really useful in finding the areas of code that are taking the most time in the test.
A few notes for 2017 and NUnit 3
You also want to use the following arguments
--inprocess
Runs the tests in the same process so the profiler can profile your code.
--where:cat==Profile-Me
Use this instead of
/include: Profile-Me
because it's obsoleteHere is an example of my settings