Visual Studio can be quite viral in my life. When I am “into” something or having to pick up a new technology or methodology, it is where I reside. This Sunday morning; it is a comfortable place to be!

The new project I am working on and the Entity Framework, in particular, are the objects of my latest bout of obsession.

I have had a particularly good week; for the first time in my current role, I am writing tests prior to code. Logging in on the weekend when there is nothing that has to be done is a very good indication of my happiness in work.

Scoping a task in tests is one of my favorite elements of TDD (and software development as a whole.) The effort to make the test suite be the best documentation of the elements they test is one that makes perfect sense to me. Developers will write document business rules which will be validated each time the test suite is run. In addition, I like writing tests; they increase my understanding of what I am doing.

Today whilst writing some tests utilising some legacy code (Legacy code is any code without tests!), I encountered a null reference exception as references to the HttpContext have made it into the business layer I was using. No IIS … No HttpContext … Thanks to Jason Bock and his wonderful article I will be back in business tomorrow!

I was sold after I added the following test to his tests. The cache object in particular was something I wanted to “mock”.

public void UseCache()
  HttpContext context = (new MockHttpContext(false)).Context;
  context.Cache.Add("test", "test value", null, DateTime.Now.AddMinutes(1),
    TimeSpan.Zero, CacheItemPriority.Normal,null);
  Assert.AreEqual(context.Cache.Get("test").ToString(), "test value");
  Assert.AreEqual(HttpContext.Current.Cache.Get("test").ToString(), "test value");

The article is well worth a (re-) read as it is a great “how-to” for using Reflector

Monday rolls around and again I find myself blogging on the train ride home reflecting on my day. The similarity of the words mundane and Monday is never lost on me on Monday mornings. The commute is dreary with seldom a smile to be had from the disgruntled masses. Follow that with the weekly development meeting, updates on the previous week’s support calls and all told lunchtime Monday is the “true” start of my week.

After the midday sustenance it seems motivation levels in my office are at a really good level. Having dispensed with our earlier mentioned administration tasks we are on to the nitty-gritty of our various projects. This weeks is one I hold quite dear; the automation of unit tests for the user interface.

I spent a thoroughly enjoyable afternoon constructing the first of automated tests using WatiN along with the three other members of my team. It was “quad” programming at it’s best! In addition to bringing us all on to the same page regarding the use of the new tool to automate IE, the session yielded an impromptu “style” to the tests and helper methods we intend to create. Hopefully, tomorrow we can apply the lessons of this afternoon to the tasks of scripting the tests for the newest component of our software suite.

WatiN (Web application testing in .NET) is based upon WatiR and is an open source tool for automating the testing of Web applications. It comes with all it’s source code (in C#) , a test recorder and MS Excel importer.

Some WatiN resources:

WatiN Project
Adam Esterline’s Blog

Later in the week I shall review how I have found it to use but thus far indications are positive.

In my new role at Biomni, we use TypeMock as a mocking framework. My experience of mocking is quite limited so I haved embarked on an investigation of what features are afforded within the Community Version of TypeMocks and more poignantly how to go about using them.


  • Simple Mocking
  • Return Values
  • Throw Exceptions
  • Check Sent Arguments

Posted by Craig Murphy on his blog The Social Programmer

Seen as Benjamin Mitchell’s MSN Messenger caption:

NAnt, NUnit, NCover, NWorries

After spending a spare two minutes on Kevin Rutherford’s Blog Silk and Spinach I was moved to ask Google to define Jidoka.

A Japanese term for autonomation. Stopping the production line whenever a defect is discovered.

Red bar!! Sounds a lot like TDD to me. Apologies to Kevin as he does not like the term test driven development.

I am a little perplexed right at the moment. If I am to isolate all my unit tests and leave the testing environment as it was at the beginning of my test, how can I add records to a database? Won’t my PK sequence bugger things up if I am using IDENTITY primary keys?

There is a little voice in my head screaming “Transactions”. More investigation! So some time passes, google churns and out pops DataFresh. At first glance it would seem to be a solution to returning the database to it’s pre-test state. Or not doing so as the case may be, which seems key to perfomance.

I was pleased to drill a bit into the site and find that Roy Oshergrove has given the folks at Entropy Zero a look.

Next Page »