Compiling .NET Projects Using Rake

Before I get into too much detail, wanted to credit Sean with doing the work on this, I just ripped what he did off. :)  I just wanted to document the basics of getting a build script written using Rake that can compile your solution and run your unit tests locally.

We have it running on Team City as well, and I'll blog more about that as I learn it. :)  It does support it out of the box.

The rakefile

First thing you need to do, of course, is intall Ruby, RubyGems, and then the rake gem. Some links on this are below.

Next, in your project, create a text file and name it rakefile.rb.  In my example, I placed this in my project root (at the same level as all of my .NET project folders and solution file).  What I’m doing with rake here is having it compile my solution, and run my tests using Gallio.Echo (the command line runner for MbUnit).  It compiles the solution by passing in the correct params to msbuild.

   1: require 'fileutils'

   2: include FileUtils

   3:  

   4: version = 'v3.5'

   5: compile_target = ENV.include?('target') ? ENV['target'] : 'Debug'

   6: project = "MyProject"

   7: framework_dir = File.join(ENV['windir'].dup, 'Microsoft.NET', 'Framework', version)

   8: msbuild = File.join(framework_dir, 'msbuild.exe')

   9:  

  10: task :default => :build

  11:  

  12: task :build => [:compile, :test] 

  13:  

  14: task :compile do

  15:     sh "#{msbuild} #{project}.sln /property:Configuration=#{compile_target}"

  16: end

  17:  

  18: task :test do

  19:     runner = 'tools\\Gallio\\Gallio.Echo.exe'

  20:     assembly = "Test\\bin\\#{compile_target}\\MyProject.Test.dll"

  21:     extension = '' #'/e:TeamCityExtension,Gallio.TeamCityIntegration'

  22:     sh "#{runner} #{assembly} #{extension}"

  23: end

  24:  

  25: desc "Rebuild"

  26: task :rebuild do

  27:   sh "#{msbuild} #{project}.sln /t:Rebuild /property:Configuration=#{compile_target}"

  28: end

  29:  

  30: desc "Clean"

  31: task :clean do

  32:   sh "#{msbuild} #{project}.sln /t:Clean /property:Configuration=#{compile_target}"

  33: end

So the first part of the file allows us to set the environment variable containing target info.  Here we default to Debug if nothing is set.

Then we set up a default task, which allows us to just type in “rake” in the command line without passing parameters (on line 10).  This means we default to the “build” task.  The following line then set up dependencies on that task, and indicated that when we call build, we want to run the compile and test tasks.

The compile task simply passes in the appropriate info to msbuild.exe.  The test task simply passes in the correct parameters to Gallio.Echo.exe to run our tests.

That’s really it.  As you can see, rake isn’t doing much but delegating to different applications, but if your builds are more complex, it can definitely help manage things (like loops, etc) if they are necessary in your build script.

Resources

Download ruby: ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.8.7-p72-i386-mswin32.zip


RubyGems: http://rubyforge.org/frs/?group_id=126


Building with Rake: http://testdrivendevelopment.wordpress.com/2009/02/01/nant-sucks-and-rake-rocks/

“Controllerless” MVC: A high-level overview of my attempt

So there has been a lot of talk recently about doing away with controllers in MVC. My first read of it was from when Brian first mentioned it. The concept didn’t gain much traction until the discussion was renewed by Chad Myers’ post, which was then followed up by another post from Brian and then Jeffrey Palermo’s post. Phew! In any case, the basic concept is to map a request to one or more commands that are relevant for that request. The purpose of the command is simply to return data, that’s it. It should have no knowledge of anything regarding the request (no Context, no Request or Response objects).

I liked the idea but didn’t have a chance to work on it, until now. I have a new project I’m starting up at work and thought it would be a good chance to try my hand at seeing how I could implement this sort of framework.

Why I Don’t Like Controllers

Part of my current job is upgrading some existing sites to use the ASP.NET MVC framework. As I was doing this, one thing kept bugging me: the controller was doing too much! Not only did I have to retrieve data, but I also had to know how to validate it, save it, redirect to the appropriate view if necessary, etc. Since one controller had to manage every action on a single page, it quickly became large. Frankly, I felt like we were moving back towards the web forms code-behind model, where everything the page needed was in its code-behind.

The other aspect I didn’t like about how the framework worked (out of the box) was that, even when using partials, the main page still needed to contain all of the data so that it could send the correct model to any partials that implemented it. This didn’t feel right to me. At least when I did Model-View-Presenter in web forms I could have user controls that contained their own presenter, so that the containing page really didn’t need to know anything about what the controls were doing, or what data they needed. This was a step back, in my opinion.

So Why Did I Do What I Did

From Scratch vs. Utilizing ASP.NET MVC
What I am currently doing on my new project is attempting to implement the concept above (one request to one or more commands). I was torn between starting from scratch, or building it on top of the existing ASP.NET MVC framework. I decided to do the latter, as I thought the MVC framework was extensible enough to plug in my command implementation, and it also kept me from having to reinvent the wheel (ex: rendering the correct view, routing, etc).

The basic concept is I implemented was to create a single controller (utilizing the front controller pattern) that handled all requests. This would then find and call “Execute” on the correct commands. Finally, the value returned from the Execute method would be loaded to the ViewDataDictionary.

I also liked the idea of building on top of the MVC framework because it will make it simpler down the line for me to upgrade our existing projects to use this new approach, should we decide to.

Why Not Use Existing Ideas?
The first answer to this is because I thought this would be fun. :) The second is none that are out there didn’t quite meet the need, as I saw it. For example:

• FubuMVC still revolves around a controller.
• Jeffrey Palermo’s spike (linked above) simply limits a controller to one action, definitely better but not quite there.
• Subcontrollers (via MvcContrib) require passing in the parent controller as a parameter to the action – eek! I definitely don’t want to be coupling controllers like that.

So How Did I Do It

Before I go into too much detail, a word of warning: nothing of what you see here is anywhere near production ready. My hope was to get some ideas out there and let people go from there (or, if my ideas suck, now they know what not to do).

Now that that’s out of the way, here are some notes on what I did. The code below is purposely incomplete, as I’m still developing this. As it gets more mature I will put it all on Google code to be downloadable, but not just yet.

The Controller and Controller Factory

As I mentioned above, the ASP.NET MVC framework is pretty extensible, so you can create your own custom versions of many of the classes it uses under the covers to work. The first thing I did was to create my own controller factory. Its main purpose in life is simply to create my front controller. It can also do one other thing, but that is outside of the scope of this high level post. In any case, here’s my factory:

   1: public class ConfigControllerFactory : CommandControllerFactory

   2: {

   3:     public override IController CreateController(RequestContext requestContext, string controllerName)

   4:     {

   5:         var commandController = new ConfigController();

   6:         return commandController;

   7:     }

   8: }

You’ll notice that it extends the CommandControllerFactory class (an abstract class with one method that I won’t get into now). You can also see that all it’s doing is returning my front controller. Here’s that controller:

   1: public class ConfigController : CommandController

   2: {

   3:     public override Type[] CommandTypes

   4:     {

   5:         get { return typeof (MyCommand).Assembly.GetTypes(); }

   6:     }

   7: }

This also implements an abstract class, CommandController, which does all of the magic (I’ll show more of it later). The purpose of this controller’s implementation is to pass to my abstract controller all commands that exist in my system.

So theoretically by implementing these two abstract classes, your web app can now use this framework. That is of course, after some additions to the global.asax.

Global.asax Changes

The first thing I changed is the default route data. Since we no longer are using controllers, I didn’t like the idea of having {controller}/{action} in my route. The MVC framework uses the controller value to find the controller, so it’s moot now anyway. So I changed my route to be the following:

   1: routes.MapRoute(

   2:     "Default",                                              // Route name

   3:     "{context}/{action}/{id}",                           // URL with parameters

   4:     new { controller = "Command", action = "DefaultAction", id = "" }  // Parameter defaults

   5: );

I liked the idea of “context” and “action” because it better showed how the commands are grouped. We have a context (like an account) and an action (saving a new account). Yeah it’s a rip-off of the BDD naming style, but I felt it was appropriate.

The other thing I had to add to the global.asax was to set the MVC framework up to use the correct factory. I did this by adding this to Application_Start:

   1: // Tell the MVC framework to use the CommandControllerFactory to create controllers.

   2: ControllerBuilder.Current.SetControllerFactory(typeof(ConfigControllerFactory));

That’s it!

The CommandController

This class is where the magic happens. Again, it’s early on (and therefore not very clean), so forgive the code. It is simply here as a reference, not as a production ready “copy and pastable” class.

The CommandController inherits from the MVC framework’s Controller class and overrides two methods: ViewResult and ExecuteCore.

ExecuteCore is where the request first comes in. At a high level, we get the context and action from the route data object, and from that we generate a unique key, which lets us map a request to the appropriate commands. Here are the simple properties:

   1: private string Context

   2: {

   3:     get { return RouteData.GetRequiredString("context"); }

   4: }

   5:  

   6: private string Action

   7: {

   8:     get { return RouteData.GetRequiredString("action"); }

   9: }

  10:  

  11: private string ContextActionKey

  12: {

  13:     get { return string.Format(NamespaceFormat, Context.ToLower(), Action.ToLower()); }

  14: }

Now that we have that key, the ExecuteCore method simply loops through all of the actions, and executes any that contain that key in their namespace. This is the link between a request and its associated actions. That way a request can execute any number of relevant actions. Here’s the loop:

   1: foreach (var commandType in CommandTypes)

   2: {

   3:     // If it's a command, execute it

   4:     if (typeof(ICommand).IsAssignableFrom(commandType) && !commandType.IsInterface)

   5:     {

   6:         // Ensure the command is in the correct namespace for the view - we only want to execute commands related to the current view

   7:         if (commandType.Namespace.ToLower().Contains(ContextActionKey))

   8:         {

   9:             var commandObject = IoC.Resolve(commandType) as ICommand;

  10:  

  11:             // Add result to ViewData if one was returned

  12:             ExecuteCommandAndLoadResultToViewData(commandObject);

  13:         }

  14:     }

  15: }

And here’s how we store whatever is returned from the command’s Execute method call:

   1: result = commandToExecute.Execute();

   2: if (result != null)

   3: {

   4:     try

   5:     {

   6:         ViewData.Add(result.GetType().FullName, result);

   7:     }

   8:     catch (ArgumentException)

   9:     {

  10:         throw new ArgumentException(string.Format("The type: {0} has already been added to the ViewData collection", result.GetType().Name));

  11:     }

  12: }

So the basic concept is each model is a unique entry into the ViewDataDictionary (for better or worse). This allowed me to create generic base classes for all of my views to inherit from. Basically it’s a class that takes a generic type. The view inherits from this class, passing in the model it expects as the generic type. Then the class retrieves the model object from the ViewDataDictionary. This means my views are now independent of the commands, they only know what model to look for in the dictionary. This also means I can create truly independent partials, since they do not rely on models being passed into them.

Summary

So there’s a lot more I didn’t touch on (like how to load an object from the view model, so that the command can use it). That will be coming up in my next posts. I’m just hoping this whets your appetite, and also generates feedback to improve this functionality.

Philly .NET Code Camp Notes

So this Saturday I had the fortune of giving a presentation on design patterns at the Philly .NET code camp. I think there's definitely room for improvement, but overall I think it went ok.

Per some people's request, here is the link to my code repository (hosted on Google code): http://design-patterns-demo.googlecode.com/svn/trunk/

This includes both the slides and the complete source code.

Mapping a Generic List to a List of SelectListItems

One thing I came across several times on my current project is converting a list of items to a list of SelectListItems in order to bind them to an MVC drop down list.  In the interest of making this task easy (and to keep from repeating code), I decided to create an extension method that uses Func<T,R> and Predicate<T> parameters so that it can be used with any list of objects.

The Code

Here is the extension method:

   1: /// <summary>

   2: /// Maps generic list of items to a list of SelectListItems for use in a drop down list.

   3: /// </summary>

   4: /// <typeparam name="T">Object which is being converted to a SelectListItem</typeparam>

   5: /// <param name="itemsToMap">List of objects to map to a list of SelectListItems</param>

   6: /// <param name="textProperty">Property on the object being mapped whose value should be placed in the Text property of the SelectListItem</param>

   7: /// <param name="valueProperty">Property on the object being mapped whose value should be placed in the Value property of the SelectListItem</param>

   8: /// <param name="isSelected">Condition indicating if the current SelectListItem should have Selected set to true</param>

   9: /// <returns>List of SelectListItems</returns>

  10: public static IList<SelectListItem> MapListToListOfSelectItems<T>(this IList<T> itemsToMap, Func<T, string> textProperty, Func<T, string> valueProperty, Predicate<T> isSelected)

  11: {

  12:     IList<SelectListItem> selectListItems = new List<SelectListItem>();

  13:  

  14:     foreach (var item in itemsToMap)

  15:     {

  16:         SelectListItem selectListItem = new SelectListItem();

  17:         selectListItem.Value = valueProperty(item);

  18:         selectListItem.Text = textProperty(item);

  19:         selectListItem.Selected = isSelected(item);

  20:         selectListItems.Add(selectListItem);

  21:     }

  22:     return selectListItems;

  23: }

How it Works

As you can see, this code can work with any list of items by using lambdas to retrieve the appropriate property values.  A SelectListItem requires three properties to be filled in, the text string, the value, and whether or not it should be set to selected in the list it is bound to.  Extension methods require the first parameter to be the class that is being extended, so in this case we’re extending any IList<T> object to have this functionality.

The second parameter (textProperty) is a lambda that points to the property in the object being mapped that contains the value we want to put in the Text property of the SelectListItem.  Inside the foreach loop, the line “selectListItem.Text = textProperty(item)” is doing this work, by retrieving the value from the given property on “item”.

The third parameter (valueProperty) is similar.  It gets the value from the supplied property and passes it to the Value property on the SelectListItem.

The final parameter (isSelected) is a Predicate, which means any function that returns a boolean value.  In this case, we want to be able to pass in to this method the criteria that will indicate whether or not this SelectListItem should be selected when the list is bound.

Seeing it in Action

So here’s an example of how to use this extension method.  In this example, we will have a simple Person class, which simply has a Name and Id.  Now, our functionality needs to return a list of Persons that have been mapped so that we can bind them to a drop down list.  The other requirement is, if we’re editing a person, we want them selected by default.

Here’s the Person class:

   1: public class Person

   2: {

   3:     public string Name { get; set; }

   4:     public int Id { get; set; }

   5: }

Now we’ll have a method that does the mapping.  It will take in the list of Persons to map as well as the Id of the person being edited (so that we can determine if it should be selected in the list).

   1: private IList<SelectListItem> MapPeopleToSelectListItems(IList<Person> peopleToMap, int idOfPersonBeingEdited)

   2: {

   3:     return peopleToMap.MapListToListOfSelectItems(x => x.Name, x => x.Id.ToString(), x => x.Id == idOfPersonBeingEdited);

   4: }

So in this example, we’re simply setting the Name of the person object to the Text property of the SelectListItem, the Id of the person is the Value, and the current SelectListItem should be selected if the Id of the person is equal to the Id of the person being edited.

This has been a handy little method that hopefully is useful to you as well.

(Almost) Frictionless Testing: Integration

In my previous post, I discussed how one impediment to adopting TDD (or testing in general) is running into a series of headaches in attempting to write a test.  Once a large amount of friction is encountered, testing will be thrown out the window.  This is true either because the programmer gets frustrated, or the schedule dictates swift completion of code, and it is thought that skipping the writing of tests will speed things up.

A while ago I wrote a post on how to simplify integration tests, and the basic principles I mentioned there still stand for me:

My personal requirements that I believe make setting up an integration test relatively simple and effective … [are] the following:

1. The ability to pass sample data into a method so that you can write tests against it
2. The ability to allow data that you don’t care about to be dynamically generated behind the scenes so that you don’t have to worry about it
3. The data generated by the tests should be easy to clean up so that the database is left in a clean state

Tests for Mappings

In light of that, I decided to update what I’ve learned since then and show my new code that I believe makes our tests a bit simpler to write.  Specifically, I attempted to address one concern we had, and that was how to simply test our NHibernate mappings.  In our code base, we are using the DAO model (for now anyway) and our NHibernate objects are our domain objects.

To start, I began with a base test class that took in the domain object being mapped, as well as its associated DAO.  I then noticed we had some simple classes that did not have their own DAO, so I created another test class that simply took in the domain object itself.  The first test class (with the DAO) then inherits from this test class just so that we have our shared code in one spot.  In any case, let’s see how the base classes take care of my three self-imposed requirements discussed up above.

Passing in Sample Data
There are many cases when you want to have some sort of control over the data you want to save to the data store during your integration test.  For example, if object A depends on object B, you will want to be able to persist B before setting up and writing tests for A.  To do this, I have the following methods in my base class:

   1: /// <summary>

   2: /// Saves test objects to the database before setting up the system under test.  Used if the system under test

   3: /// depends on other objects existing before it can be created.

   4: /// </summary>

   5: /// <param name="objectsToSave">Set of objects to save before setting up the system under test.</param>

   6: protected virtual void SaveDependentObjectsNeededBySystemUnderTest(params object[] objectsToSave)

   7: {

   8:     foreach (var testObject in objectsToSave)

   9:     {

  10:         _manager.GetSession().Save(testObject);

  11:     }

  12: }

  13:  

  14: /// <summary>

  15: /// Virtual method used to set up test values on the system under test when the values inserted via reflect are not sufficient.  Also

  16: /// optionally will save any objects needed to correctly set up the system under test.

  17: /// </summary>

  18: protected virtual void SetUpTestDataOnSystemUnderTest()

  19: {

  20:     SaveDependentObjectsNeededBySystemUnderTest();

  21: }

As you can see, they’re both virtual, because only some tests might need to override them.  Also, they have two different purposes.  The first one saves dependent objects, the second one by default calls the first one, but can also be overridden to set up additional values on the test object.

Note that _manager is simply an instance of the NHibernateSessionManager class.

Now that we have these methods, simply call the second one in the base class’ SetUp method:

   1: [TestFixtureSetUp]

   2: public void BaseSetup()

   3: {

   4:     SaveTestDataForSystemUnderTest();

   5: }

Dynamically Generating Data

Now, the next thing we want to do is to be able to dynamically generate data behind the scenes.  This removes the need for us to set every property on the system under test each time we want to write a new test.  The simplest way of doing this, IMHO, was simply using reflection.  So my base test class takes in an instance of a class I named ReflectiveMapper, whose only purpose in life is to set values on object properties.  Here’s the class:

   1: /// <summary>

   2: /// Class used by tests to loop through the properties of an object and set each property equal to random test data, based on the

   3: /// property's type.

   4: /// </summary>

   5: public class ReflectiveMapper

   6: {

   7:     private object itemUnderTest;

   8:  

   9:     public SystemUnderTest LoadObjectUsingReflection<SystemUnderTest>()

  10:     {

  11:         itemUnderTest = Activator.CreateInstance(typeof(SystemUnderTest));

  12:         PropertyInfo[] properties = itemUnderTest.GetType().GetProperties();

  13:         foreach (var propertyInfo in properties)

  14:         {

  15:             LoadPropertyWithTestValue(propertyInfo);

  16:         }

  17:         return (SystemUnderTest)itemUnderTest;

  18:     }

  19:  

  20:     private void LoadPropertyWithTestValue(PropertyInfo propertyInfo)

  21:     {

  22:         if (propertyInfo.CanWrite)

  23:         {

  24:             propertyInfo.SetValue(itemUnderTest, CreateTestValueBasedOnPropertyNameAndType(propertyInfo), null);

  25:         }

  26:     }

  27:  

  28:     private object CreateTestValueBasedOnPropertyNameAndType(PropertyInfo propertyInfo)

  29:     {

  30:         Type propertyType = propertyInfo.PropertyType;

  31:         object testValueToReturn = null;

  32:  

  33:         if (propertyType == typeof(string))

  34:         {

  35:             testValueToReturn = GenerateRandomString();

  36:         }

  37:         else if (propertyType == typeof(int))

  38:         {

  39:             testValueToReturn = GenerateRandomInteger();

  40:         }

  41:         else if (propertyType == typeof(DateTime))

  42:         {

  43:             testValueToReturn = DateTime.Now;

  44:         }

  45:         else if (propertyType == typeof(Guid))

  46:         {

  47:             testValueToReturn = Guid.NewGuid();

  48:         }

  49:         else if (propertyType == typeof(bool))

  50:         {

  51:             testValueToReturn = true;

  52:         }

  53:  

  54:         return testValueToReturn;

  55:     }

  56:  

  57:     private int GenerateRandomInteger()

  58:     {

  59:         return new Random().Next(1000);

  60:     }

  61:  

  62:     private string GenerateRandomString()

  63:     {

  64:         return new Random().Next(999).ToString();

  65:     }

  66:  

  67:     public void SetField(object target, string fieldName, object value)

  68:     {

  69:         FieldInfo fi = target.GetType().GetField(fieldName, BindingFlags.DeclaredOnly | BindingFlags.NonPublic | BindingFlags.Instance);

  70:         fi.SetValue(target, value);

  71:     }

  72:  

  73:     public void SetIdField(object target, string fieldName, int value)

  74:     {

  75:         SetField(target, fieldName, value);

  76:     }

  77: }

First, you’ll see that it take in a generic object, so that we can reflectively load any object.  It creates an instance of it, then loads each property using the correct value associated with its type.  You’ll see that for strings and ints, I used a little trickery.  To ensure a random int, I used the built-in Random class.  However, I also wanted somewhat random strings, so I figured the easiest way to do that was simply string-ify the random ints.  That way different string and int properties are (for the most part) set with different values, which I like.

Another thing this class does is allows you to set values on properties with no setters (useful for setting IDs, which should never contain a setter, since we want NHibernate to load them, not our code).

Leaving the Database in a Known State

There are two ways that I’ve used to clean up databases after integration tests.  The first way I did it was using transactions.  The pro of this is that you don’t have to remember to delete your data once your test is complete.  The con is you have to make sure your test database has all expected tables and constraints set up before the test is run.

The second way you can do this is by running scripts.  Since the codebase I came into already had set up and tear down scripts in place, I saw no reason to change this, so that is what I’m using currently.  The pro is that the database is in a known state both before and after the tests are run.  The con is you have to manually update these scripts each time you create, update, or delete any tables in your system.

To run the scripts, we first have two .SQL files in our project, one for creating objects, another for tearing them down (basically just dropping everything in the system).  To run these scripts, we have a ScriptRunner class, which has two methods which I’ll show below.  Just for full disclosure, my co-worker Sean wrote this code, not me, so I can’t take credit for it. :)

   1: /// <summary>

   2: /// Class containing the functionality to run set up and tear down scripts for mapping tests.

   3: /// </summary>

   4: public class ScriptRunner

   5: {

   6:     private readonly string connectionString;

   7:     private const string SetupFile = @"Files\CreateObjects.sql";

   8:     private const string TearDownFile = @"Files\DropObjects.sql";

   9:  

  10:     public ScriptRunner(string connectionString)

  11:     {

  12:         this.connectionString = connectionString;

  13:     }

  14:  

  15:     public void RunSetUpFile()

  16:     {

  17:         SqlScriptRunner runner = new SqlScriptRunner(GetCommandText(SetupFile));

  18:         using (SqlConnection conn = new SqlConnection(connectionString))

  19:         {

  20:             conn.Open();

  21:             using (SqlTransaction trans = conn.BeginTransaction())

  22:             {

  23:                 runner.Execute(trans);

  24:                 trans.Commit();

  25:             }

  26:         }

  27:     }

  28:  

  29:     public void RunTearDownFile()

  30:     {

  31:         SqlScriptRunner runner = new SqlScriptRunner(GetCommandText(TearDownFile));

  32:         using (SqlConnection conn = new SqlConnection(connectionString))

  33:         {

  34:             conn.Open();

  35:             using (SqlTransaction trans = conn.BeginTransaction())

  36:             {

  37:                 runner.Execute(trans);

  38:                 trans.Commit();

  39:             }

  40:         }

  41:     }

  42:  

  43:     private string GetCommandText(string fileName)

  44:     {

  45:         string command;

  46:         using (FileStream fs = new FileStream(MakeFullPath(fileName), FileMode.Open, FileAccess.Read))

  47:         using (StreamReader sr = new StreamReader(fs))

  48:         {

  49:             command = sr.ReadToEnd();

  50:         }

  51:         return command;

  52:  

  53:     }

  54:  

  55:     private string MakeFullPath(string fileName)

  56:     {

  57:         string assemblyPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase.Replace("file:///", ""));

  58:         assemblyPath = System.Text.RegularExpressions.Regex.Replace(assemblyPath, @"bin\\.*", "");

  59:         return Path.Combine(assemblyPath, fileName);

  60:     }

  61: }

Of course there are other ways of setting up your databases for integration tests, including generating them in-memory from your NHibernate mapping files.  The purpose of what I’m showing you here is just to give you one example of how it can be done.

Comparing Values


Now, if you’re testing mapping, you want to ensure that the value in your object is the same value that was persisted to the database.  To do this, we went the route of having an object persisted, then doing a simple ADO query to retrieve a DataRow, and finally checking the values in that row and comparing them to the values in our object.  This is done by a method on our base class, which returns a ValueChecker object, which has the duty of comparing the values to see if they are equal (this also allows us to do a kind of fluid interface).  Here’s the method call along with the call to get the DataRow:

   1: protected ValueChecker EnsureThat(object valueToCheck)

   2: {

   3:     GetDataRowWithTestData();

   4:     return new ValueChecker(testDataRow, valueToCheck);            

   5: }

   6:  

   7: private void GetDataRowWithTestData()

   8: {

   9:     if (testDataRow == null)

  10:     {

  11:         SqlConnection conn = new SqlConnection(ExtractConnectionString());

  12:         SqlCommand cmd = new SqlCommand(SqlToRetrieveTestDataRow, conn);

  13:         cmd.CommandType = CommandType.Text;

  14:         SqlDataAdapter dataAdapter = new SqlDataAdapter(cmd);

  15:         conn.Open();

  16:         try

  17:         {

  18:             DataSet ds = new DataSet();

  19:             dataAdapter.Fill(ds);

  20:             testDataRow = ds.Tables[0].Rows[0];

  21:         }

  22:         finally

  23:         {

  24:             conn.Close();

  25:         }

  26:     }

  27: }  

You can see a put a class-level row DataRow variable and check if it’s null, so that I’m not hitting the database on every test in the fixture.  Next, here’s the simple ValueChecker class:

   1: public class ValueChecker

   2: {

   3:     private readonly DataRow dataRow;

   4:     private readonly object valueToCheck;

   5:  

   6:     public ValueChecker(DataRow dataRow, object valueToCheck)

   7:     {

   8:         this.dataRow = dataRow;

   9:         this.valueToCheck = valueToCheck;

  10:     }

  11:  

  12:     public void IsEqualToValueInColumnWithName(string columnName)

  13:     {

  14:         bool valuesAreEqual = (dataRow[columnName].ToString() == valueToCheck.ToString());

  15:         Assert.IsTrue(valuesAreEqual, string.Format("Values are not equal: Column name: {0}, Value 1: {1}, Value 2: {2}", columnName, dataRow[columnName], valueToCheck));

  16:     }

  17: }

The simplest way I found with the data I’m generating to see if the values are equal is to simply convert them to strings.  So far, it’s working great.  In any case, with the base class method and the ValueChecker class in place, test code could look something like:

   1: [TestFixture]

   2: public class When_mapping_a_company : MappingTestFor<Company, CompanyDao>

   3: {

   4:     [Test]

   5:     public void The_value_in_the_id_property_should_be_equal_to_the_value_in_the_ncompanyid_column()

   6:     {

   7:         EnsureValueIn(x => x.Id).IsEqualToValueInColumnWithName("nCompanyId");

   8:     }

   9: }

Finally, there is one final piece to getting this to work.  For each test fixture, we need the SQL to return the sample DataRow to test against.  For different tests, this could be different data, so for now we simply put an abstract property on the base class:

   1: protected abstract string SqlToRetrieveTestDataRow { get; }

Each test fixture then overrides this.  Using an example from the Company test above, it would look something like:

   1: protected override string SqlToRetrieveTestDataRow

   2: {

   3:     get { return string.Format("select * from dbo.Company where nCompanyId = {0}", systemUnderTest.Id); }

   4: }

The systenUnderTest object is automatically set up in the base class (via reflection, as mentioned above, as well as any data supplied in the overridden virtual methods, discussed earlier) and then saved, so there’s no need to define it or set it up elsewhere.

As always, I’m open for feedback on more improvements we can add to this test base.

(Almost) Frictionless Testing: Specifications

One sure-fire way to lose people when it comes to TDD is to encounter a lot of pain just to set up what is supposed to be a simple test. When writing simple specifications, this can come in the form of having to set up a lot of context each and every time you write a test, typically by mocking out a series of objects. In tests where you interact with the database, this can come in the form of having to set up the connection, any lookup objects, etc. And all of this before you even write a test!

As part of my tasks in my current position, I am attempting to rewrite how they do their tests in order to make them (I hope) easier to create and maintain. I am still learning a lot about testing, so this will definitely be an iterative process, but I hope each step takes away some pain that my coworkers are experiencing. For the purposes of this post, I will discuss how we’re currently writing our specification tests. In my next post, I’ll discuss how we’re doing our tests that hit the database (and why).

Specifications

Here, when I discuss specifications, I am talking about unit tests, where one object is under test and all of its dependencies are mocked. Below are some of the pains we’ve experienced, and how I’ve tried to address them. Note: a lot of the ideas here I can’t take credit for, I learned a lot of it from J.P. Boodhoo’s Nothin’ But .NET class.

Record/Playback Model
One tough concept for a lot of people was how the Record and Playback model worked in Rhino.Mocks. It wasn’t intuitive, that first you set up your expectations, then call the method under test to see what happened. Fortunately, this is now moot with the latest version of Rhino.Mocks. It now implements the AAA (Arrange-Act-Assert) syntax which makes testing a lot cleaner, so thank Ayende for removing that pain. If you’re not using the AAA syntax yet, start doing it. It makes setting up the context simpler, and your tests cleaner. The beauty of it is, the new version of Rhino.Mocks is backwards compatible, so add the new version to your project, and your old tests still work. This allows you to update your tests whenever you have time, instead of having to do all of them at once (which was very convenient when I had to update 1100 tests to the new syntax).

Setting up context (and dependencies)
Another headache when writing tests is setting up the entire context for the system under test each time. This includes mocking out each dependency the system has. Part of this pain is, again, remedied by the latest version of Rhino.Mocks. Previously, if you wanted to test an expectation, you could not also set up a result for this expectation. This would cause the test to fail. Not so with the latest version. You can set up your expected result for an expectation, and also assert that it was called. This means you can centralize your set up in one location, instead of setting up different results for each and every test. As for mocking out dependencies, this can be done using reflection (this is where I began stealing from Boodhoo). I have a base test class that all of my tests inherit from, named SpecificationsFor<SystemUnderTest>, where SystemUnderTest is a generic representing, you guessed it, what I’m actually testing. An example:

When_viewing_the_articles_page_and_a_normal_document_is_returned : SpecificationsFor<ArticleController>

The first job of the base class is to get the greediest constructor for the system under test, mock out each item in the constructor (if it’s an interface), and place those mocked objects in a dictionary, where the type is the key, and the mocked object is the value:

   1: protected SystemUnderTest sut;

   2: private IDictionary<Type, object> dependencies;

   3:  

   4: [SetUp]

   5: public void SetUp()

   6: {

   7:     dependencies = new Dictionary<Type, object>();

   8:     sut = SetUpSystemUnderTestWithMockedDependencies();

   9:     Set_up_context();

  10:     And_calling();

  11: }

  12:  

  13: protected SystemUnderTest SetUpSystemUnderTestWithMockedDependencies()

  14: {

  15:     ConstructorInfo greediestConstructor = GetConstructorWithMostParameters();

  16:     return (SystemUnderTest)Activator.CreateInstance(typeof(SystemUnderTest), MockedConstructorArgs(greediestConstructor).ToArray());

  17: }

  18:  

  19: private List<object> MockedConstructorArgs(ConstructorInfo constructor)

  20: {

  21:     List<object> mockedParameters = new List<object>();

  22:     foreach (var parameterInfo in constructor.GetParameters())

  23:     {

  24:         if (parameterInfo.ParameterType.IsInterface)

  25:         {

  26:             mockedParameters.Add(MockOfParameter(parameterInfo));

  27:         }

  28:     }

  29:     return mockedParameters;

  30: }

  31:  

  32: private object MockOfParameter(ParameterInfo parameterToMock)

  33: {

  34:     if (!dependencies.ContainsKey(parameterToMock.ParameterType))

  35:     {                

  36:         dependencies[parameterToMock.ParameterType] = MockTheParameter(parameterToMock);

  37:     }

  38:     return dependencies[parameterToMock.ParameterType];

  39: }

  40:  

  41: /// <summary>

  42: /// Mock out the parameter supplied. To do this and have it work with the new AAA syntax, we need to use the mock repository to

  43: /// create a dynamic mock, then replay the mock in order to get it out of record and into replay mode.

  44: /// </summary>

  45: private object MockTheParameter(ParameterInfo parameterToMock)

  46: {

  47:     MockRepository mockRepository = new MockRepository();

  48:     object mockedObject = mockRepository.DynamicMock(parameterToMock.ParameterType);

  49:     mockRepository.Replay(mockedObject);

  50:     return mockedObject;

  51: }

  52:  

  53: private ConstructorInfo GetConstructorWithMostParameters()

  54: {

  55:     ConstructorInfo[] constructors = typeof(SystemUnderTest).GetConstructors();

  56:  

  57:     int parameterCount = 0;

  58:     ConstructorInfo constructor = constructors[0];

  59:     foreach (var constructorInfo in constructors)

  60:     {

  61:         if (constructorInfo.GetParameters().Length > parameterCount)

  62:         {

  63:             parameterCount = constructorInfo.GetParameters().Length;

  64:             constructor = constructorInfo;

  65:         }

  66:     }

  67:     return constructor;

  68: }

Now that we have the dependencies mocked, we need to be able to access them in the test. So we have a simple accessor method that pulls the object from the dictionary:

   1: protected DependencyType AMockedDependencyOfType<DependencyType>() where DependencyType : class

   2: {

   3:     if (!dependencies.ContainsKey(typeof(DependencyType)))

   4:     {

   5:         dependencies[typeof(DependencyType)] = AMockOf<DependencyType>();

   6:     }

   7:     return (DependencyType)dependencies[typeof(DependencyType)];

   8: }

And we also have a method to simply mock an object that we might need to use during testing:

   1: protected InterfaceType AMockOf<InterfaceType>() where InterfaceType : class

   2: {

   3:     return MockRepository.GenerateMock<InterfaceType>();

   4: }

Now you no longer have to manually mock out your dependencies, and you also get (IMHO) a slightly cleaner testing nomenclature.

More on the testing nomenclature

Another thing our base test class does is give us a cleaner, more natural style when writing out expectations (again, thanks to J.P.’s ideas). We are currently using a fluid interface, which simply wraps Rhino.Mocks’ familiar Stub method (or in the earlier versions, SetupResult.For).

To do this, we have a simple wrapper class, shown below:

   1: public class ExpectationBuilder<T> where T : class

   2: {

   3:     private readonly T mock;

   4:  

   5:     public ExpectationBuilder(T mock)

   6:     {

   7:         this.mock = mock;

   8:     }

   9:  

  10:     public IMethodOptions<R> IsToldTo<R>(Function<T, R> action)

  11:     {

  12:         return mock.Stub(action);

  13:     }

  14:  

  15:     public IMethodOptions<R> IsAskedForIts<R>(Function<T, R> action)

  16:     {

  17:         return IsToldTo(action);

  18:     }

  19:  

  20:     public IMethodOptions<R> IsAskedIf<R>(Function<T, R> action)

  21:     {

  22:         return IsToldTo(action);

  23:     }

  24: }

Now the base class has a method which simply calls this class:

   1: protected ExpectationBuilder<DependencyType> WhenThe<DependencyType>(DependencyType dependency) where DependencyType : class

   2: {

   3:     return new ExpectationBuilder<DependencyType>(dependency);

   4: }

Taken together, our method to set up a context now looks something like this:

   1: // Set up dependencies

   2: contextService = AMockedDependencyOfType<IContextService>();

   3:  

   4: // Set up data returned from context  service

   5: WhenThe(contextService).IsToldTo(x => x.GetContent("content")).Return(new List<ContextKey>());

Thanks to using the new version of Rhino.Mocks, and the code you see above, our tests are much easier to set up and much cleaner – almost every test now is simply one line of code.

I would love to hear about other people's thoughts and practices when it comes to simplifying your testing.

Re-cap of the Philly Code Camp (and my code sample)

Another fall, another Philly.NET Code Camp. It was another good session of ALT.NET presentations. J.P. Toto gave a talk on the aspects of an ALT.NET project, which led to more discussion (and some debate) as to the meaning of the ALT.NET name. While some of it is the same old argument rehashed (why do you hate Microsoft?), some points were interesting, and it'd be nice to see them brought up at the Philly ALT.NET group meetings.

Brian Donahue gave a good introduction to the concept of mocking which I enjoyed and thought people found very useful. The nice part was seeing the differences between different types of mocking (fakes, stubs, etc). Jon Graves gave a well-attended talk on using WPF with Model-View-Presenter-type coding for testability. It was a good example of keeping the principles of testability with new UI technology. Steve Eichert gave a redux of his IronRuby presentation, which is a good introduction to Ruby in general as well as a nice example of Ruby in action.

My presentation wrapped up the track, and I thought it went pretty well. It was the same talk I gave at the last camp on building testable forms with MVP, and I enjoyed the number of questions I got this time, and the discussion that ensued. Overall, a good day.

As promised, below you will find a zip file which contains both the code and the slides, as well as some links discussing the MVP pattern.

• Code and slides
• Martin Fowler discusses the MVP pattern, and its types: supervising controller and passive view
• Code Project article with MVP code examples
• Good Phil Haack post on MVP, with some more advanced code examples