Staff Intranet on Codeplex

I have not posted here for a little the main reason being I have been putting the final touches to another project I have been working on in my spare time, it’s a staff intranet application what I have tried to do with this project as with the previous projects is try and use it as a learning exercise, so I have incorporated some best practices and design patterns and used them for a real world example, in there you will find:

  • Inversion of control – This has been decoupled from a particular IoC container but I have utilised Castle Windsor under the hood
  • TDD/BDD – Around 98% of the behaviour of the application was designed test first, the reason I have put BDD as well is because I like to think of my tests as defining the behaviour of the application rather than of just testing assertions in my code, this comes out through the naming of my test cases
  • NHibernate – This was my first use of NHibernate and overall I was very pleased with what this very powerful ORM gives you and also keeping the domain clean from database artifacts (persistence ignorance)
  • Model View Presenter – This is the first time I have emplyed model view presenter for web and it acts as a nice interim between moving logic from the codebehind and going the whole hog and using an MVC framework such as monorail or ASP.NET MVC, I’m completely sold on having tests against the UI logic
  • SQL Server 2005 – This was probably the most dissapointing aspect of developing this application, I was hoping that the new client tools would be great and easy to get stuff done with however I found it the opposite things that used to be easy using the SQL server 2000 enterprise manager were not intuituve at all with the Management Studio, examples:
    • Wanting to remove a database that already exists
    • Setting permissions from the users perspective

Anyway after that intro you can find more details over at my project homepage on codeplex.

My hope is that this project will help others who are learning about the above but would like to see them used in a real world context rather than just in hello worls context.


First codeproject article posted

I just finished posting my first article to codeproject (only taken 3 years since I joined!), it covers unit testing against a database and also provides a handy little testing library that can be used to make it a little easier you can check it out at

Unit testing threading using rhino mocks

Update: I have recently put together a much more detailed look at this in my obstacles of unit testing series

I recently had to do some unit testing against my TaskScheduler class this presented a problem… the TaskScheduler performs it’s monitoring by spawning a worker thread in the background so I needed a way to test this asynchronous behaviour. Thanks to the excellent Rhino Mocks and using the ManualResetEvent I come up with the following solution:

public void Should_run_scheduled_task_when_datetime_met()
	ManualResetEvent evt = new ManualResetEvent(false);
	DateTime runAt = new DateTime(2008, 1, 1, 12, 0, 0);
	ITask mockTask = mocks.DynamicMock();
	ITaskRunner mockTaskRunner = mocks.DynamicMock();

	using (mocks.Record())


		LastCall.On(mockTaskRunner).Do(new TaskRunnerRunDelegate(delegate(ITask task)

	using (mocks.Playback())
		ITaskScheduler sut = createSUT(new MockDateTimeSource(runAt.AddSeconds(-2)), mockTaskRunner);
   	        evt.WaitOne(4000, false);

When a Task that the TaskScheduler is monitoring reaches its scheduled execution date/time the TaskScheduler Hands off to an ITaskRunner in this case it’s a mocked out interface, we can use this to listen out for a call to the Run method, and set the ManualResetEvent thus exiting the WaitOne block. The downside to this approach is establishing what the timeout should be in most cases this will be a few seconds.

Dealing with NUnit test fixtures that don’t get on

When we want to test the behaviour for a particular object is working correctly we setup a unit test method and mock it’s dependencies such as it’s data access that way we can setup expectations and run the tests without requiring items such as a running database or an available web service, but eventually if we want to cover ourselves we are going to need to test that the data access code talks to the database correctly. If we aren’t careful these tests could slow down the running of the non data access tests this can lead to developers neglecting to run tests if they start taking longer and longer to run one way to deal with these troublesome unit tests in NUnit is to supply a Category attribute on the fixture class

[Category("data access tests")]
public class MyTestFixture

Then by using the Categories tab you can add the new category to the selected categories list and then choose to exclude these categories, When you switch back to the Tests tab the tests in this category are greyed out and can be ignored, then when you come to do some work on data access code you can include the category and check you haven’t broken anything!