TDD with Monorail – Part 3

I have created a layout and stylesheet which will do for now, at least it will look like a system. I usually find that if I can have the html from a designer before starting on a page this helps smooth the development of the UI quite nicely.

Part 3 sees us create our first integration spec. I am going to create a test which will check that there is a page at “…/Admin/Users/Register.pnx” and that the page has a title of ‘Register’.

A bit of housekeeping – I have setup IIS to use a virtual directory called ‘TimEscott.GrassRoots’ which points to my web project directory, this virtual directory also has a ISAPI mapping setup on it for the ‘.pnx’ extension, the file extension that I have chosen to use for my application, this is setup in IIS 7 using a script map. This file extension for the application is configured in the web.config, we are also refusing access to the view files themselves.

      <add verb="*" path="*.pnx" type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, Castle.MonoRail.Framework" />
      <add verb="*" path="*.vm" type="System.Web.HttpForbiddenHandler" />

Integration test class structure

I have setup a IntegrationSpecsBase class which all my integration tests will inherit from. This gives some common functionality for building up URLs to pages in my system and inheriting all the useful stuff in Monorails BaseControllerTest. Here is my IntegrationSpecsBase class.

using Castle.MonoRail.TestSupport;

namespace TimEscott.GrassRoots.Specs.Integration
    public abstract class IntegrationSpecsBase : BaseControllerTest
        protected string BuildTestUrl(string path)
            const string URL_FORMAT = "http://localhost/TimEscott.GrassRoots/{0}";
            return string.Format(URL_FORMAT, path);

The requirement that I am going to tackle first is #6 “For unregistered Users to be able to register”. For this I will require a registration page on which a user will be able to submit some account details to create a new account. Now this is quite a large requirement and one which will need breaking down into smaller chunks before I can tackle it effectively. I am not going to document these smaller requirements here, I will let my tests document them.

My User Registration specification


The intention of the naming of the class and the test is that it should be able to read like a sentence. So this should read “When registering a user <the> users controller should display the registration view”. So the class name is very close in name to original specification #6. The intention is that the individual tests start to break down the over all requirement into smaller chunks that I can then go off and spec, test and then implement. I will experiment with naming the item under test, in this case the UsersController, subject and see how I feel about that particular convention as things move on further.

As you can see from the screen grab re-sharper is complaining somewhat about an undefined type, namely my UsersController. Well this will be because I haven’t created it yet being test first and all! So to satisfy the compiler I will go an create the UsersController class, re-sharper finds the newly created type and asks if I want to add a using statement to my testfixture, I add the using but still the compiler complains. I need to make the new UsersController inherit from the Monorail SmartDispatcherController. Now the compiler is happy I can finally run my tests.

I have a few tools available to me to run the tests, TestDriven.Net, NUnit GUI or the re-sharper test runner. I am going to experiment with all 3 until I find a favourite. I will run this test suite by using TestDriven, I have bound “Alt + T” to TestDriven to run the tests in context. Here are the results at this stage.


Right, well I know that I haven’t created the view, the action or put the text in the view. I was expecting the test to fail. So I am going to do the simplest thing I can to get the test to pass, I.e. Create the view, action and insert the text. After adding the new controller to the Windsor config, running the test again confirmed that I have satisfied this part of the overall specification.

Right that will do for this post, next time hopefully we will get a bit deeper into the architecture.


~ by Tim on 17 July 2008.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: