Posts Tagged 'Test Driven Development'

Creating a Testable Client-side ViewModel with Knockout

In my previous post, I discussed why I a JavaScript MVC or MVVM framework is essential: It lets you prove, quickly and conveniently, that your code works so that you can assemble applications out of reliable components. In that post I also started on a project to show how one of those frameworks—Knockout—supports the MVVM design pattern. I also created the server-side methods that my application (an ASP.NET View that displays information for a customer selected by the user) would need. However, what I created were mock functions that I could use for testing. In this post, I’ll start to create the client-side resources my application would need while still focussing on testing the code.

Setting Up the Client

My first step on the client (after adding the Knockout library to my Scripts folder, of course) is to add the necessary script references to my layout page to support using Knockout. For testing purposes, I also include a RenderSection that will allow me to selectively add script references on a View-by-View basis. This basic set of references is used by every View:

<head> <meta charset="utf-8" />  
 <link href="@Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />  
 <script src="@Url.Content("~/Scripts/jquery-1.5.1.min.js")" type="text/javascript"></script>  
 <script src="@Url.Content("~/Scripts/knockout-2.0.0.js")" type="text/javascript"></script>

With those references in place I’m ready to start generating some client-side code. First, I add a Javascript file to my Scripts folder to hold the Customer ViewModel that I’ll developer. Again, to support testing, I add a variable called controller to the file that will let me redirect my server-side requests to my mock methods:

var controller = ""; 

Now I can (finally) start defining my ViewModel, beginning with the properties that hold the data my page will both display and allow users to update. I define those properties using Knockout’s observable function:

var Customer = function (custIdIn) { 
 this.CustId = ko.observable(); 
 this.CompanyName = ko.observable(); 
 this.City = ko.observable(); 

Using the observable function gives me two-way databinding (the ViewModel automatically updates the View’s elements, the View’s elements automatically update the ViewModel). Other Knockout functions support handling arrays and computed values. I don’t have to use the observable function—if I only wanted the data to flow from my Customer ViewModel to the elements on my page, I could skip using the observable function.

I also define a variable to refer to the current value of this (my ViewModel). I’ll need a reference to my ViewModel later and defining self at this point in the ViewModel’s code bypasses any of the ways that this gets redefined:

var self = this; 

My next step is, still in my Customer ViewModel, to define a function that uses jQuery’s getJSON method to retrieve data from my server-side methods. I’m going to call this function getCustomer and have it retrieve the Customer object from my server-side methods. Once the JSON object is retrieved, the code updates my ViewModel’s properties from the JSON object’s properties. This is one of the places that I use the self variable I defined earlier to avoid problems with this being redefined. I also use my controller variable to define the URL used to access the service:

this.getCustomer = function (custId) {
  $.getJSON("/" + controller + "/CustomerById/" + custId, 
 function (cust) { 
 self.City(cust.City); } ); }; 

Because my CustId, CompanyName, and City properties are really Knockout observable functions, I must use the syntax shown here to update their values. This ensures, for instance, that changes to the CompanyName and City properties will automatically be reflected in any elements in my page that the properties are databound to.

Testing a JavaScript ViewModel

I’ve got enough functionality written at this point to begin testing (too much, actually, for a real TDD approach—I should have started writing my tests before I put any code in my getCustomer function). In my last post, I defined a controller (TestController) and an action method (CustomerViewModelTest) to use for testing. I can now create the View that will be called from that action method (CustomerViewModelTest.cshtml). I use QUnit for testing client-side code, so I need to add the files Qunit needs (a JavaScript file and a CSS file) to my application. However, I’d prefer not to download those files on every page so I don’t add those references my layout View. Instead, in my test View, I add the references to the Header section that my Layout View references. I also add a reference to the JavaScript file holding my Customer ViewModel that I want to test:

@{ ViewBag.Title = "Customer ViewModel Tests"; } 
@section Header { 
 <script src="@Url.Content("~/Scripts/CustomerVieModel.js")" type="text/javascript"></script>  
 <link href="@Url.Content("~/Content/Tests/qunit.css")" rel="stylesheet" type="text/css" />  
 <script src="@Url.Content("~/Scripts/qunit.js")" type="text/javascript"></script>  

In the body of my page, I add in the headers that QUnit needs to execute and display test results:

<form action="/Test/index">
 <h1 id="qunit-header">Customer MVVM Tests</h1>
 <h1 id="qunit-bannder"></h1>
 <div id="qunit-testrunner-toolbar"></div>
 <h2 id="qunit-userAgent"></h2>
 <ol id="qunit-tests"></ol>

I can now test my ViewModel using QUnit’s test function. I set my controller variable to direct all my getJson requests to the mock methods on my Test controller. I use jQuery to prevent my tests from running until the page is fully loaded:

controller = "Test"; $(function () { 

That test consists of instantiating my Customer ViewModel, calling its getCustomer method passing a customer Id, and checking to see if the ViewModel’s properties were updated correctly. Since I’m making an asynchronous server-side call, I can’t simply call my getCustomer method and check the property results—my test code might run faster than my server-side call and check the property before the result is returned. To get around that, I use QUnit’s asyncTest and JavaScript’s setTimeout functions to wait for one second before checking the result using QUnit’s equals function:

var cust; test("Get Customer", 
 function () { 
 cust = new Customer("Test"); 
 setTimeout( function () { 
 equals(cust.City(), "Regina", "Customer not retrieved"); 
 start(); }, 
 3000); } ); 

I can now run my tests and see the results by calling my CustomerViewModel action method on my TestController (and, of course, my test passes the first time).

At this point I have a testable ViewModel but, of course, that’s not much good unless it supports a real page. That’s what I’m going to look at in my next post. But with this framework in place, I know that I’m building my page with something that works.

If you’re looking for a course with a good introduction to TDD in Visual Studio, Learning Tree’s Design Patterns and Best Practices in .NET course is a good choice. However, Learning Tree’s ASP.NET MVC course devotes a whole chapter to TDD with ASP.NET MVC.

Peter Vogel

Creating Testable Applications with a JavaScript MVC Framework

I love test driven development because, assuming that I’m going to test my code at all, the TDD frameworks make testing much easier and faster—much faster than running the whole application in order to test a few lines of code, for instance. The problem is that my usual JavaScript + jQuery coding practices defeat TDD.

My usual practice is to present users with a page where, for instance, they can select a customer from a dropdown list in order to see the information on that customer. In my JavaScript code, I use the customer Id from the dropdown list to access a service that returns the appropriate JSON object. I then start moving that data to the page using jQuery to select the elements that I want to update with data from the JSON object. And this is where the wheels fall off, at least as far as TDD goes: I can’t claim that I’ve tested my code unless I’ve tested the jQuery code and I can’t test my jQuery code without providing the page with the elements that my jQuery code is updating.

But this is exactly the problem that the Model-View-Controller design pattern is intended to solve: Have all the code/logic in the controller where it can be tested with TDD; have a separate View that is too simple to have much wrong with it and, as a result, doesn’t require testing. What I want, then, is an MVC framework that lets me put all my JavaScript code in a Controller that doesn’t need a View to be tested. Then, in my View, I want to integrate with my controller in a declarative “code-free/logic-free” way that doesn’t require testing. Oh, sure, in my View I can still have what I call “blunders” (e.g. misspelled text; the right data in the wrong place) but I can’t have logic errors that require debugging.

There are several frameworks that will do that. Lately, I’ve been using one of them—Knockout—on a project for one of my clients. Knockout implements the MVVM pattern which includes a ViewModel object that wraps up both the code and the data that drives your View creating, in the ViewModel, a very testable object. Knockout also provides declarative databinding to elements in my page to move data to my elements without code. In addition to Knockout’s basic functionality there’s lots to like about Knockout. For instance, it’s very easy to implement: download the Knockout library from, add it to your Scripts folder, and add a script reference to your page. Knockout also relatively agnostic about how you retrieve your data, making it easy to integrate with either WCF or ASP.NET MVC. I’m going to do this in easy stages, starting with this post that sets up my server-side resources.

Setting Up the Server

As an example, I’m going to walk through creating a page with Knockout using ASP.NET MVC. Since, with TDD, I begin with my tests, I first a controller called Test to my application, with an action method to support displaying a View that will let me test my client-side Customer ViewModel:

public class TestController : Controller {
 public ActionResult CustomerViewModel() {
 return View();

My client-side Customer ViewModel is going to need to retrieve Customer objects from my server. Since I’m working in ASP.NET MVC, I’ll add an action method to my controller to support that. However, I’ll just return some mocked up objects for testing purposes. This ensures that, when I’m testing my Customer ViewModel, I really am only testing my Customer ViewModel and not my server-side code or database connection. That mock method looks like this:

public ActionResult CustomerById(string id) {  
 Customer cust = Customer.CreateCustomer(id, "PHVIS", null); 
 cust.City = "Regina";  
 return this.Json(cust, JsonRequestBehavior.AllowGet); 

Learning Tree has several excellent courses in this area. I get to teach both Learning Tree’s ASP.NET MVC course and its Design Patterns and Best Practices course. But Learning Tree also offers courses on JavaScript and jQuery.

Peter Vogel

Unit Testing ASP.NET MVC with MvcContrib

One of the big drivers for people moving over to ASP.NET MVC is its support for Test Driven Development/Unit Testing. The ability to automate testing of models and controllers brings a measurable level of confidence to development. In ASP.NET MVC, that means we can be sure that we are getting the expected views, data and routes from our controllers.

Unless they do something that only works in a Web context, in which case we get an exception.

The problem is that the Visual Studio Test Framework isn’t a Web client. The moment your controller does something that only works in a Web context, like accessing a session variable, your test will break with a NullReferenceException.

Screenshot of NullReferenceException

The controller in the test project has a Session property – but if you try and set Session variables, you will simply move the NullReferenceException up one level into your test project. That’s where MvcContrib comes in. It’s an open source project available at CodePlex, and it allows you to mock up the HttpContext and populate the Session etc. with the values your methods require.

Once you’ve downloaded MvcContrib, you need to set a reference to it inside your test project. The classes you want are inside the TestHelper namespace, so add it as an Imports. Then get the TestControllerBuilder to create the controller for you – that will give you the extra framework you need to add in the HttpContext elements. The easiest thing to do is add a controller variable at the class level, and then call CreateController() inside a TestInitialise() method.

code sample creating controller

The TestControllerBuilder gives you a more fully featured version of the controller. Now, if you set a Session variable, the value will be passed through to the controller and you won’t get the NullReferenceException in either the test project or the controller.

code sample setting Session variable in test code

So now you can run your tests and have them pass – even when your code has elements that require a HttpContext.

screenshot successful tests

One gotcha to watch out for. You need to have a mocking framework available – so make sure that you also reference one of the mocking frameworks that works with TestHelper or you’ll get an exception when you try to run your tests. In the sample above, I referenced Rhino.Mocks, which is included with MvcContrib.

MvcContrib has quite a lot of other features beyond testing, and I might well come back to some of those in later posts.

Kevin Rattan

For other related information, check out these courses from Learning Tree:

Building Web Applications with ASP.NET MVC

.NET Best Practices and Design Patterns: Hands On

Learning Tree International

.NET & Visual Studio Courses

Learning Tree offers over 210 IT training and Management courses, including a full curriculum of .NET training courses.

Free White Papers

Questions on current IT or Management topics? Access our Complete Online Resource Library of over 65 White Papers, Articles and Podcasts

Enter your email address to subscribe to this blog and receive notifications of new posts by e-mail.

Join 29 other followers

Follow Learning Tree on Twitter


Do you need a customized .NET training solution delivered at your facility?

Last year Learning Tree held nearly 2,500 on-site training events worldwide. To find out more about hosting one at your location, click here for a free consultation.
Live, online training

%d bloggers like this: