Using MS Test on the Forget the Milk Application

Substituting MS Test for NUnit in Wes Higbee's Confident Coding: A Journey to Automated Testing in ASP.NET MVC #

I'll start by saying this is based on the above mentioned course on Pluralsight. Wes Higbee does an AMAZING job of illustrating how to get into Test Driven Development (TDD) or Test First Development (TFD). Wes Higbee's website.

I am transitioning from a self taught independent full stack developer to a member of a team for a larger scale project so this "Journey", as he calls it was very necessary for getting me into the right mindset for this project.

I decided to write this post to help anyone who may want to simply use the built in Microsoft Testing framework instead of using NUnit for this course. THIS IS NOT A REPLACEMENT FOR THE COURSE. Please do the course, it's worth the time if you are in a position like I am, or you are trying to wrap your head around automated testing.

You can see all the test code I wrote in this GitHub Project Here.

Some examples of the minute differences are listed below:

So here are some snippets of the basic differences. Essentially the MSTest code (dark) utilizes the [TestMethod] attribute where as NUnit uses the [Test] attribute.

You'll also notice some differences with the Assert area of the test. The NUnit version of the test utilizes the Expect method because the CreateTaskTests inherits from the AssertionHelper class that comes with NUnit. While this is easier to read it does operate in the reverse order of the MSTest Assert method.

Most of the test methods are incredibly similar except for the differences in the Assertion portion. There is however one exception where the arranging portion of the test differs and the MSTest version is a bit more chaotic looking.

The DueDate method is a little unique, because it it leverages some additional NUnit functionality, namely an attribute called [TestCase()].

That code looks like this:

So as you can see this functionality is actually pretty handy. However, MSTest requires us to be a bit messier to get the same functionality:

There is a side effect of doing this in our test window. Using the TestCase attribute the method will actually be displayed in the TestExplorer 12 times. The MSTest way of doing this does indeed check all 12 cases, but the test is a single test. This makes it harder to Debug any specific cases.

One of the last major differences to talk about is the how to handle the "Throws" method that NUnit provides to test for exceptions. Bradley Braithwaite has a great article and has a method that can be used to add this functionality on his blog here. I did the most simplistic solution albeit it is not perfect. Choosing Brad's solution by implementing your own Throws method is probably the best case, but the following code will help you scrape by:

Alternatively you could always write the tests more optimally to accommodate the MSTest framework, but like I said this code will help you finish the project.

Using NUnit or building out your own Throws method will look like the following:

The rest of the tests utilize these same techniques. Additionally the above GitHub repo I mentioned has all of the tests written and working in MSTest as well. I apologize for using screen snippets instead of actual code. As this blog progresses I'll try and post copy-able code.