Category Archives: Unit Testing

Unit Testing in VS 2013

Visual Studio 2013 now contains functionality to write tests against a Windows Store project. Now, it is a relatively simple task to write unit tests against the code you have in classes within your app’s structure.

A Basic Example

Launch Visual Studio, and from the new project dialog, select Templates -> Visual C# -> Windows Store, and create a new “Blank App (XAML)” named “AppToTest”. Make sure you change the Solution Name value to be “TestableStoreAppExample”


Within the project, create a new folder named “DataAcccess”, and within that a new class named “SampleDataAccess.cs”

Open your newly created class, and mark it as public.

Now we want to add some methods to the class. These will be the methods against which our tests will run, so we will just create some dummy ones for now.

As you can see, the content of the class is very basic at this stage. We will build on this later.

Build the project to ensure that there are no errors.

Next, Let’s add a unit test project.

Right click on the solution in Solution explorer, and click on “Add -> New Project”. In the dialog, select “Unit Test Library (Windows Store Apps”, and name the test project “AppTests”.

In the unit test project you just created, right click on References and select “Add Reference”. In the dialog that appears, navigate to “Solution” on the left hand side, and select “AppToTest on the right, then press OK.

02 - AddReference

Now we can write some tests. For now, I’m just going to add these tests into the default class created when the project was initialised.

Open the file “UnitTest1.cs”

There are couple of annotations to note in this class, but these should be familiar to you if you have used MSTest before.

[TestClass] Marks the class as being a test fixture, containing unit test code.
[TestMethod] Marks a method as being a Unit Test.

For our first test, I’ll re-use the code already in the class. First of all, let’s change the name of TestMethod1 to something more descriptive. Since this test will call the GetSumOfInts method we defined earlier, lets call it TestIntegerSummation().

To break that down, first I create a new instance of the SampleDataAccess class, and call the GetSumOfInts method with 1 and 2, hopefully giving a result of 3. The final lines is where the test comparison happens. In this case, I’m calling Assert.AreEqual to test that the expected value of 3 matches the actual returned value. There are a few other Assert. methods available, e.g. Assert.AreNotEqual, Assert.IsTrue, etc.

Now build the solution in order to make the test available to the test engine.

To run the method, my preferred method is to open the Test menu in Visual Studio, and select Windows -> Test Explorer.


From here you can run all tests, or right click on a test name to run individual ones. (Note, theres another feature that you might want to take advantage of – automatically run tests when you build the solution. To do this, go to Test -> Test Settings and select “Run Tests After Build)

The screenshot above shows that the test we wrote passes.

OK, that’s a synchronous method. What about async ones?

Testing async Methods

This isn’t as intuitive as you might imagine, but once you know the trick, it’s very simple.

As you saw when we created the class to test, I created an async method that goes off and pulls text from a web resource. This is an async call due to the potential delays in loading a web resource.

To create a test for this, we first need to define a new method in the test class and decorate it with the [TestMethod] attribute, then write the code we want to call in the method.

If we do this with the same signature as before, however, the test won’t appear in the test explorer. There are two things we need to do to make the test runnable.

1) Add the async keyword to the method signature (to allow the use of the await keyword in the method call)

2) Change the return type of the test method from void to Task (in the System.Threading.Tasks namespace)

Our method should now look like this.

The test now shows up in Test Explorer and you can run it just like any other method.

More Complex tests

Another great way to test methods is by the use of the [DataTestMethod] attribute. This attribute allows you to specify many sets of data to run in the test, without the need to refactor a test to support different values.

Let’s take our TestIntegerSummation() test and refactor that to support different data sets.

Make a copy of the method, and call it TestIntegerSummationWithData, and add three integer parameters to the signature, calling them “input1”, “input2” and “expectedResult”.

Next we need to update the method body to use these values. The result should look like this.

Change the Attribute from [TestMethod] to [DataTestMethod].

To add sets of data against which we want the tests to run, we can add additional attributes, in this case, the [DataRow()] attribute.

Each DataRow attribute allows you to specify values to be used within the method (in the order they are defined in the method signature). The data we want to pass in should be a reasonable set of data that can be used to test various conditions, but for the purposes of this post, we’ll just pick some random values and test those.

You can see that there are likely to be some edge cases where the calculation will not return the expected result, for example, if we set input1 to be Int.MaxValue. In that case, running the test will show the following in Test Explorer – you can see it gives individual results for each DataRow defined.


There are a couple of ways to handle this situation. We can simple extend the method signature and data rows to pass in a value of whether we expect the test to pass or not

But this isn’t an ideal situation, especially if we expect an exception.

I’ll talk about better ways to handle this in the next post.

Syncfusion e-books

Syncfusion have released a series of e-books on various topics, including Windows Store Apps. You need to enter some registration information to be able to access them, but the content looks good at first glance – certainly good enough to make it worth registering.

Unit Testing MVVM Light Messages

MVVM Light has a messenger implementation which can communicate with the UI layers in order to handle things like page navigation, and using this is is very easy to set up a PCL ViewModel assembly to drive both a Windows 8 and Windows Phone app. As a quick example of how you’d set this up, imagione this implementation in a view model.

where NavigationRequestMessage and NavigationTarget are implemented as follows.

Now you can handle the incoming message in your front-end app. In this example, it’s in a Windows 8 Store app.

Note that we unregister the handler again on navigating away from the page, otherwise the message will be handled twice next time we visit the page, three times the next time, etc.)

Now we can write a unit test for this method to ensure that whatever our actual implementation logic tell us should be the resulting navigation is actually correct…

This is a trivial example, but hopefully it explains how to test the navigation in your apps when driven by MVVM Light’s Messenger functionality.

Another Unit Testing trick

So, you’re about to start an MVVM Windows Phone app, and you really want to be able to run unit tests against your view models using Visual Studio’s built-in test engine.

By default, you can’t do that for a phone app – you need to create a Phone Unit Test App that will wrap everything and spit out the test results when you run the app.

If you really want to be able to run tests within the IDE you can build your view models in a separate Portable Class Library (yes, those again). As long as you add .NET as a target framework for the VM library, you will be able to write your tests in the same way as you would for any other project type.

Of course, this approach is not appropriate for all functionality – for phone-specific functionality you will need to use the default (separate app) approach, or a mix of the two.

Unit testing gotcha

In the course of writing unit tests on a project, I came across in interesting wrinkle for testing MVVMLight ViewModel classes. When creating a ViewModel, the work is actually done on different thread which leads to the following unit test code throwing an exception.

Instantiating the SummaryViewModel class leads to the following exception message being displayed.

The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))

The solution is relatively simple, though. First I create a method to allow me to run an action and marshal its result back to the appropriate thread.

And then I created a method specifically to create the SummaryViewModel, since I will be doing that many times across my unit tests.

Then it is just a matter of changing my test method to call CreateViewModel and await the result, and all is good.