Listing issues

Here we are again. We left the last installment with 3 passing tests which is a good start. In this installment we’ll create an acceptance test for creating a new issue and start the work of displaying a list of created issues.

But first things first, I think I need to expand on one subject from the previous post that I didn’t really cover and that is Moq, the mocking framework I’m using (for the first time). So, in Create_Success unit test, here is the code to mock out our IIssueRepository:

So what’s happening here? Well, Moq uses Lambda expressions to define how to mock out calls. In the first line above we create our mock object for the IIssueRepository interface (notice we don’t have an implementation of this interface yet). The next line defines what method of IIssueRepository (r) Moq should expect to be called and when it does, what it should return. In this case, IIssueRepository has a Save method that returns the saved object. Notice that we set the controller property IssueRepository to mock.Object rather than just mock. That’s it! I’m sure we’ll see some more complex examples as we go on.

Anyway back to development. We’ll start with a new acceptance test which will request the Issue/New view, complete the form with test data and click the save button. It’ll check that the summary of the issue created is then present on screen as we’ll be showing the list of created issues. Here it is (click for a larger version):

As before this test fails. This is because the controller IssueRepository is null, so we need to create an implementation and configure Windsor to inject it. So I’ve created a new class inside the Core assembly called IssueRepository, it implements IIssueRepository and is derived off of the PixelDragons.Commons ARRepository<T> where T is our Issue class:

To inject this class using Windsor I’ve added it to a new configuration file in the web application called Repositories.config and referenced it in the web.config. I’ve also created a blank database called pixeldragons_pixelbugs and setup the connection string in the Facilities.config. In addition I’ve added ActiveRecordStarter.CreateSchema() to the GlobalApplication. This will recreate the database schema each time the application starts up. So watch out for that. It’s good enough for now, but this will be another area to address as we develop further.

Running the acceptance test again fails. This is because we don’t have a List action in our controller or a corresponding view file. So let’s start by adding a unit test for the List action:

This doesn’t compile at first, so I added an empty List method to the issue controller. This fixes the build and this test fails as expected. We now have two failing tests. To fix the List_Success test, we just need to add the following:

To fix the failing acceptance test we need to add the list view file. Here it is:

Running the tests again, all 5 pass!! Very cool.

Now we have these tests passing I had a look at the database that ActiveRecord created for us and noticed that the issue description field has been created as nvarchar(255) which is the default string type. As we are using SQL Server 2005, we really want this field to be nvarchar(max), a simple change to the Property attribute for the Description property in the Issue class fixes this:


I also then made a small change to the New Issue view to change the description text box to a text area with some basic css styles to at least make the pages viewable (nothing fancy).

OK, you may have noticed a couple of minor housekeeping changes to the tests. I’ve added an App.config which contains the server, port and url extension to use for acceptance tests and the override for BuildUrlInfo in the unit tests. I’ve moved the BuildUrlInfo method into a new unit test base class called ControllerUnitTestBase which derives itself from BaseControllerTest. There is also a new base class for the acceptance tests called AcceptanceTestBase. This class has a single method at the moment called BuildUrl which basically takes the controller and action names as parameters and builds a url from these and the items stored in the App.config file. This base class also now contains the TestFixture attribute with the ApartmentState setting that is required for WatiN to run correctly. The final minor change is the default redirect in Default.aspx which now points to the issues list, so you can now run the application and start adding issues. Obviously we have a long way to go before this is a usable application, but we are on the road.

Here is a very rough list in no particular order of things that we’ll be looking at in the next few installments:

  • Add some extra properties to Issue such as date created, priority, status, etc
  • Improve the css styles and start work on the UI
  • Add users, permissions and a login page
  • Allow users to be assigned to issues
  • Improve the issues list by adding paging, searching and filtering

The latest code is committed to subversion, you can get it from here:

Svn Revision: r6


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: