jb's Blog

"behold the turtle, he only makes progress when he sticks his neck out"

ASP.NET and MVC – Part 2 – UnitTests for the Model

In our earlier instalment we embarked on setting up an ASP.NET MVC using LightSpeed, jQuery, Ninject and NUnit and started by building up our domain model in LightSpeed.

So it is about time we moved on to setting up our UnitTests project and got underway but getting some initial tests in for our model. So lets get started..

Some minor tweaks since last time..

Before we get started, I should mention I have quickly tidied up some of the code from last time – namely I have renamed the namespaces for this solution to be FilmFestival.* rather than lacking a top level namespace as we did previously when we set up our Model project.

I have also updated the LightSpeed model to generate into the namespace FilmFestival.Model and not prefix the generated UnitOfWork so we can find it at FilmFestival.Model.UnitOfWork.

You can do this in the entity designer by altering the Name and TargetNamespace properties accordingly.

One other tweak I had to make was to update the property definition for Cinema.GeoLocation to be a string rather than an object (which is what the LightSpeedDesigner see’s it as in SQL 2005 mode since the underlying SQL type is a SQL 2008 geography). If I was using the SqlServer2008 provider we could natively use the SqlGeography type on our LightSpeedEntity, but that isn’t released yet

Back to the tests!

So first we need to set up a new project for our unit tests, I generally call this UnitTests (original is my middle name..), and we will start by adding references to our Model project, the LightSpeed assemblies and to NUnit.Framework which is what we will use for our testing. You could use XUnit, MBUnit, MSTest or whatever takes your fancy – I prefer NUnit for the time being

The last reference I generally add is to Newtonsoft Utilities.NET which has some useful classes for testing entities. You should check this out in general as there is plenty of useful stuff in there, plus it was made by local ninja, crime fighting bat by night and occasional Supreme Commander victor James Newton-King

Managing Reference Assemblies

At this point we have started making use of some 3rd party assemblies, namely NUnit and Utilities. They may not be standard on other developers machines or on my build server, so I want to reference them from a relative path within my project structure. If you read my earlier post on project structure, you will know we should have a Lib folder for holding our reference assemblies together with the source for the project to make it more portable.

Setting up a TestFixture

The test fixture is your container for tests and allows the test framework (NUnit) to locate appropriate groups of tests to be executed. In a simple sense, what we would do is mark every class which contains tests up with a [TestFixture] attribute (found in NUnit.Framework) and that would be enough. Because we are generally likely to have common groups of tests separated across a number of files (e.g. 1 class for each model entities tests) I like to use base classes to help keep the common behaviour together.

So first off, lets provision a base TestFixture class.

  
[TestFixture]
public abstract class TestFixture    
{
    protected static LightSpeedContext&lt;Model.UnitOfWork&gt; _context;      
    public Model.UnitOfWork UnitOfWork { get; set; }
 
    static TestFixture()
    {        
      InitializeLightSpeed();
    } 
 
    public static void InitializeLightSpeed()
    {
      // TODO
    }
 
    private TransactionScope _transactionScope;
 
    [SetUp]
    public virtual void SetUp()
    { 
      _transactionScope = new TransactionScope();     
    }
 
    [TearDown]     
    public virtual void TearDown()     
    {    
      _transactionScope.Dispose();     
    }
  }

What this does is set up the framework for us to run transactional based tests against the database where the resulting transaction will always just be thrown away after each test execution – this is what we are doing with the TransactionScope in the [SetUp] and [TearDown] methods.

The last bit is we want to initialize LightSpeed. This can be done one of two ways, either from configuration or in code. For your standard applications we would recommend you use configuration, for tests, building up the context programatically is usually preferable.

So lets fill out the InitializeLightSpeed method as follows:

public static void InitializeLightSpeed()       
{         
  _context = new LightSpeedContext&lt;Model.UnitOfWork&gt;()         
  {           
    ConnectionString = @"server=localhost;database=FilmFestival;integrated security=sspi;",           
    Logger = new ConsoleLogger(),
    PluralizeTableNames = false         
  };
}

Hopefully thats obvious enough as to what we are doing here. The LightSpeedContext is effectively a factory which will instantiate us units of work which we will use to scope our interactions with the repository. For the test scenarios it will be one unit of work per test, so we can add a UnitOfWork = _context.CreateUnitOfWork(); call into the [SetUp] method to round this off.

Now whenever we access the property UnitOfWork from in our text fixtures, it will be instantiated and ready for us to do some work, and that work will always be rolled back at the end of the test regardless of what happens.

Setting up some Model Tests

Lets create some tests for our Cinema entity. For Entities, I generally have 3 stock tests (as below) before we add in anything specific to the behaviour of this entity. These tests are just there to validate we can find things and that the entities properties are at least all being checked for assignment using the ClassTester from Utilities.NET.

public class CinemaTests : TestFixture
{       
  [Test]
  public void FindOne()       
  {
      Cinema cinema = UnitOfWork.FindOne&lt;Cinema&gt;(300); 
 
      Assert.IsNotNull(cinema);       
  } 
 
  [Test]
  public void FindAll()       
  {
      Assert.AreEqual(12, UnitOfWork.Cinemas.Count());       
  } 
 
  [Test]
  public void Properties()       
  {
      ClassTester tester = new ClassTester(new Cinema());
      tester.IgnoredProperties.Add("EntityState");
      tester.TestProperties();       
  }
}

You can see we are using a mixture of LightSpeed’s query syntax (FindOne) and LINQ (UnitOfWork.Cinemas.Count()) in these tests. Generally if you are using .NET 3.5 you will be using LINQ as your primary syntax.

Oops, We need some Test Data

Ok run the tests up. And it fails. That’s good What are we missing? Oh yes, some test data. I have added in a Data.sql to our schema directory with some initial test data to cover our model so far, and one of the other things I like to add now is a little batch file to automate rebuilding things. You can have a look through both in the Schema folder in the attached code drop.

What else can we test?

In our earlier instalment we had added a helper property on to our Cinema which returned a parsed string with the co-ordinates of the Cinema’s location, so it would be good to validate our assumptions around its behaviour.

e.g.

    
  [Test]
  public void Coordinates()       
  {
      Cinema cinema = UnitOfWork.FindOne&lt;Cinema&gt;(300);
      Assert.AreEqual("-41.2947,174.7841", cinema.Coordinates); 
 
      cinema = new Cinema() { Name = "Foo" };
      Assert.AreEqual("0,0", cinema.Coordinates);       
  } 
 
    [Test]       
    public void CoordinatesAreZeroWhenGeoLocationIsNullOrEmpty()
    {         
      Cinema cinema = UnitOfWork.FindOne&lt;Cinema&gt;(300);
 
      cinema.GeoLocation = null; 
 
      Assert.AreEqual("0,0", cinema.Coordinates); 
 
      cinema = UnitOfWork.FindOne&lt;Cinema&gt;(300);
 
      cinema.GeoLocation = String.Empty; 
 
      Assert.AreEqual("0,0", cinema.Coordinates);       
    }

And so on..

Because your domain model should be playing a fairly important role in the application it is important to make sure it is well tested. I prefer using the ClassTester to cover the basics of assignment to catch any silly errors and then write specific tests for known behaviours. Your personal approach may vary, but look to achieve a fairly high level of coverage for your model.

I would also highly recommend TestDriven.NET or Resharper to give you IDE integration to execute tests via shortcut keys in scope of whatever you are currently working with (single test, test class, whole project, whole solution) which speeds things up quite a lot.

Playing along at home?

Here is the code and associated database setup script (remember to create a database called FilmFestival and run the scripts under the context of that database first or use the Build.cmd script) to cover what we have done so far. Also remember to download and install LightSpeed.

Download FilmFestival2009_Part2.zip (94KB)

Ok – What’s next?

Next we are ready to get our MVC site itself underway, then we can build out some actual functionality.

Add your comments
Author icon

Posted by Jeremy Boyd on 16 March 2009

One Response to “ASP.NET and MVC – Part 2 – UnitTests for the Model”

[...] to VoteASP.NET and MVC – Part 2 – UnitTests for the Model (3/15/2009)Sunday, March 15, 2009 from http://www.mindscape.co.nzIn our earlier instalment we embarked on setting up [...]

ASP.NET MVC Archived Blog Posts, Page 1 Mar 19th, 2009