This post outlines my (with help of others) solution to keeping my unit tests working in the absence of TestContext.BeginTimer() and TestContext.EndTimer(). These seem to be missing in Visual Studio 2012 and I can’t find any posts… so I assume no one else uses this pattern.
What’s Broken?
Here is a sample unit test that demonstrates the problem. It’s a very simple test:
- [TestMethod]
- public void Simple_TestContext_TimeingTest()
- {
- // Arrange
- var timerName = TestContext.TestName;
- // Act
- TestContext.BeginTimer(timerName);
- // Assert
- Thread.Sleep(100);
- TestContext.EndTimer(timerName);
- }
When I run that test in Visual Studio 2012 I get the following:
What? A System.NotSupportedException: Specified method is not supported? It worked fine in previous versions of Visual Studio. As I said, I have lots of tests like this.
What Should I Do Now?
I routinely used these two methods to look at performance between alternative approaches. When I upgraded to Visual Studio 2012 I got a Method Not Supported exception. So I wondered if I should update all my tests to instead use a System.Diagnostics.Stopwatch, or if I should develop a derived class from TestContext and implemented the methods. I chose the later.
Deriving from TestContext
The post “How do I derive from TestContext class and implement from base members” provided the information I needed to get started. While snotman’s motivations were different, a twist on his approach was just what I needed to keep this change short.
So here is the critical portion of my class that does that:
- public class TestContextWithTimer : TestContext
- {
- private TestContext _contextInstance;
- private Dictionary<string, Stopwatch> _stopwatches;
- public Dictionary<string, Stopwatch> Stopwatches
- {
- get { return _stopwatches ?? (_stopwatches = new Dictionary<string, Stopwatch>()); }
- }
- public TestContextWithTimer(TestContext context)
- {
- _contextInstance = context;
- }
- public override void AddResultFile(string fileName)
- {
- _contextInstance.AddResultFile(fileName);
- }
- public override void BeginTimer(string timerName)
- {
- Console.WriteLine("Timer Name: " + timerName);
- if (!Stopwatches.ContainsKey(timerName))
- Stopwatches.Add(timerName, new Stopwatch());
- _stopwatches[timerName].Start();
- Console.WriteLine("Start Time: " + DateTime.Now);
- }
- public override System.Data.Common.DbConnection DataConnection
- {
- get { return _contextInstance.DataConnection; }
- }
- public override System.Data.DataRow DataRow
- {
- get { return _contextInstance.DataRow; }
- }
- public override void EndTimer(string timerName)
- {
- if (!Stopwatches.ContainsKey(timerName))
- throw new InvalidOperationException();
- Stopwatches[timerName].Stop();
- Console.WriteLine("End Time: " + DateTime.Now);
- Console.WriteLine("Timer Duration: " + Stopwatches[timerName].Elapsed);
- }
So with that code I rewrote the original test to look like this:
- [TestClass]
- public class TimingTest
- {
- public TestContext TestContext { get; set; }
- public TestContextWithTimer TestContextWithTimer { get; set; }
- [TestInitialize]
- public void Initialize()
- {
- TestContextWithTimer = new TestContextWithTimer(TestContext);
- }
- [TestMethod]
- public void Simple_TestContextWithTimer_TimeingTest()
- {
- // Arrange
- var timerName = TestContextWithTimer.TestName;
- // Act
- TestContextWithTimer.BeginTimer(timerName);
- // Assert
- Thread.Sleep(100);
- TestContextWithTimer.EndTimer(timerName);
- }
That yielded these results instead:
Now I’m not sure what would happen if you have complicated cases with overlapping timers. However, for my unit tests this met my needs. So I’ll be writing this, now that I’ve proved it in some simple tests, to help me get past the strange missing capability in Visual Studio 2012.
I hope this helps others that might be facing this issue.
Cheers – Karl
I think you must have something to do with either configuration or installation.
I just tested the same thing and it works for me.
TestContext.BeginTimer(“mytest”);
System.Threading.Thread.Sleep(5 * 1000);
TestContext.EndTimer(“mytest”);
and here is the out put
Timer Results:
Timer Name: mytest
Start Time: 11/26/2012 11:16:18 PM
End Time: 11/26/2012 11:16:23 PM
Timer Duration: 00:00:05.0007454
I’m on Visual Studio 2012 installed on Windows 8 Pro x64. You’re on VS 2012?
After project is upgraded, old dll references are used. I had exactly the same issues. Make sure that references for UnitTestFramework and LoadTestFramework point to IDE/PublicAssemblies (not ReferenceAssemblies).
Thanks so much! I’ve not had a chance to try it yet, but that makes a lot of sense. And that explains why some posters here didn’t have the issue. Some were upgrading as I was, others (without the issue) weren’t.
I hope your comment helps others too.
According to the following Microsoft blog, http://blogs.msdn.com/b/geoffgr/archive/2014/08/05/adding-timers-to-coded-ui-tests-running-in-load-tests.aspx, the ability to use timers in a Unit test was removed from Visual Stuido 2012. The blog states that the timer still works when a unit test is placed inside a load test, but standalone, the unit test will throw the System.NotSupportedException. The blog states that a workaround is to use the following line of code just before the beginTimer() call:
if (TestContext.Properties.Contains(“$LoadTestUserContext”)) //running as load
textContextInstance.BeginTimer(“MyTimerName”);
This approach is working on my installation of VS2012, and allows me to have the timers in my unit test and to run it as a single user without putting it in a load test. Removing the functionality in CS 2012 was NOT a swift move by Microsoft. I have found some cases where a timer in unit tests still does not work in VS 2013, but then sometimes it will work in 2013. In any case, in VS 2012, “unit test timers” are consistently broken but the above line of code provides a workaround.
I added the public reference, but still get the not-supported exception. I created a new test project and compare the new to my existing. There are definitely reference and build differences. From my limited knowledge of MSBuild, It looks like running the tests in VS2010 will use the correct assembly.