To write a testable presentation layer using MVVM

In the case of a traditional application in the Windows forms era, the standard test practice is to lay out a view, write code in the code-behind file for that view, and then run the application for testing. Fortunately, after that, there have been some changes in related practices.

The advent of Windows presentation Foundation (WPF) has elevated the concept of data binding to a whole new level. It enables the development of a new design pattern called the model-view-view model (MVVM). With MVVM, you can separate the presentation logic from the actual representation. Basically, this means you can avoid writing code in the view's code-behind file to a great extent.

This is a significant improvement for those who are interested in developing testable applications. Now you do not have to represent a code-behind file that is logically attached to the view with its own lifecycle (and thus complicate the test), but you can use a normal old CLR object (POCO). The view model has no lifecycle constraints on the view. You can instantiate and test a view model in a unit test.

In this article, I'll show you how to get started using MVVM to write the testable presentation layer for your application. To help illustrate my approach, I am here to provide sample code in an open source framework (called Charmed) that I have written, along with the accompanying sample application called Charmed Reader. This framework and the sample application can be found on the GitHub (github.com/brentedwards/charmed).

I introduced the Charmed framework as a Windows 8 framework and sample application in a July 2013 article (msdn.microsoft.com/magazine/dn296512). Then, in the September 2013 article (msdn.microsoft.com/magazine/dn385706), I discussed how to implement Cross-platform applications as a Windows 8 and Windows Phone 8 framework and sample application. In both of these articles, I talked about the decisions I made to keep the application testable. Now, I'll discuss these decisions again and explain how to actually start testing the application. The examples in this article take Windows 8 and Windows Phone 8 code, but you can apply these concepts and methods to any type of application.

About the sample application

The sample application that explains how I started to write a testable presentation layer is named Charmed Reader. Charmed Reader is a simple blog reader application that can be run on Windows 8 and Windows Phone 8. It has the minimum functionality required to illustrate the points I want to cover. This application can run across platforms and is almost identical on two platforms, except that Windows 8 applications take advantage of some features that are specific to Windows 8. And the application is basically the same, with enough functionality required for unit testing.

What is unit testing?

Unit testing is to get discrete blocks of code (units) and write a test method that uses the code as expected, and then test to see if the expected results can be achieved. This test code runs with some kind of test tool framework. There are a variety of test tool frameworks that apply to Visual Studio 2012. In the example code, I used the built-in MSTest in Visual Studio 2012 (and earlier). The goal is to have a single unit test method face a specific scenario. Sometimes, you need to use multiple unit test methods to cover all the scenarios that you expect your methods or properties to apply.

Unit test methods should follow a consistent format for other developers to understand. The following formats are often considered best practices:

Arrange

Act

First, you might want to write some setup code to create an instance of the tested class and any dependencies it might have. This is the arrange part of the unit test.

After you have finished setting up the actual test phase for the unit test, you can perform the related methods or properties. This is the ACT section of the unit test. You can use the parameters set in the Arrange section (if applicable) to perform related methods or properties.

Finally, after the related method or property has been executed, the test needs to verify that the method or property's running results are exactly the same as expected. This is the Assert portion of the unit test. In the assertion phase, the assertion method is invoked to compare the actual result with the expected result. If the actual results meet expectations, the unit test passes. The test fails if it does not match.

My tests follow this best practice format, which usually looks like the following:

          [TestMethod]   
public void Sometestmethod ()   
{   
  //Arrange   
  //*insert code to set up test   
  //ACT   
  //*insert code to CAL L The method or property under test   
  //Assert   
  //*insert code to verify the test completed as expected   
}

Some people use this format but do not include comments that invoke different parts of the test (Arrange/act/assert). I like to use annotations to separate these three parts, just to make sure that you keep track of the actual test content or when you set it up.

Another benefit of having a complete set of well-written unit tests is that they can act as a living document for that application. New developers looking at your code can see the different scenarios involved in these unit tests to see how you expect to use the code.