Oct 31, 2009

Test the Right Thing

I was helping a customer recently to improve the way they do testing and I looked at one of their tests as follows:

[TestMethod]
public void FeedFileProcessorResolvesLoadDirectoryViaFeedType()
{
  MockRepository mocks = new MockRepository();
  using (MockServices services = new MockServices(mocks))
  {
    FeedType feedType = MockServices.CreateStubFeedType(1001, null, null, @"z:\PickUpDirectory");
    Expect.Call(services.FeedTypeProvider.GetByFeedTypeID(feedType.FeedTypeID))
      .Return(feedType);
    mocks.ReplayAll();

    MockFeedFileProcessor.DefaultFeedTypeId = 1001;
    FeedFileProcessor processor = new MockFeedFileProcessor();
    string loadFilesFrom = processor.DirectoryToLoadFilesFrom.FullName;

    mocks.VerifyAll();

    Assert.AreEqual(@"z:\PickUpDirectory", loadFilesFrom);
  }
}

On first glance it seems reasonable.  The test is named so that it describes what it does and seems to work through checking that the object behaves as it should. Sure the Rhino Mocks syntax could be updated to use AAA syntax, and the using section doesn't really indicate what's going on under the hood there but apart from that it doesn’t look too bad.

Look a little closer though and check out the class under test and you may see a small problem.  That’s right, the only class being tested here is the mock itself.  Not something that you really want to do.

By not actually testing a class from our production code we’ve made the test have zero value for the system itself.

Oct 23, 2009

Architecture in the Small Presentation

Last night I was privileged to be the first speaker at the newly formed Sydney Architecture User Group put together by Paul Glavich (@glav) and Omar Besiso (@omarbesiso) and sponsored by Datacom.

There was a strong turnout and plenty of people in the audience willing to ask questions.  I’ve uploaded my slide deck from last night to Slideshare in case you weren’t able to make it there in person or you just wanted to go back over it for yourself.

Oct 16, 2009

How to Make Linq to NHibernate’s Expand() Type Safe

Linq to NHibernate is great.  It makes your queries so much easier to understand since it expresses the intent of what you are doing better than the CreateCriteria API does.

For example compare this statement:

var query = session.CreateCriteria<UserProfile>()
  .Add(Restrictions.Eq("Id", identifier))
  .SetFetchMode("Sites"), FetchMode.Join);
var result = query.UniqueResult<userprofile>();

with this:

var query = from p in session.Linq<UserProfile>().Expand("Sites")
  where p.Identifier.Equals(identifier)
  select p;
var result = query.SingleOrDefault();

To me, the second is much easier to read, especially if you have people who aren’t familiar with NHibernate trying to read your code.  The only problem with both of these queries is the use of those nasty magic strings.  What happens if I refactor my UserProfile class and rename the Sites collection to something like PublicSites?  Obviously my query will no longer work as expected but I’d only find that out when I ran my integration tests (or at run time if I happened to be lazy and don’t write tests).

I want to avoid all that magic string nastiness and lean on the compiler to help me out, so I planned to write some extension methods to improve the situation, but do that and reinvent the wheel? After all, Marcin Budny has done all that wheel-inventing already and made the extension methods available from his blog.  Sweet!

Now I can get rid of that “Sites” magic string and write strongly typed code that looks like this:

var query = from p in session.Linq<UserProfile>().Expand(u => u.Sites)
  where p.Identifier.Equals(identifier)
  select p;
var result = query.FirstOrDefault();

Isn’t that so much nicer :-)  Thanks Marcin for making your code available!

Sydney Architecture User Group, Oct 22nd

Just thought I’d let you all know that I’ll be speaking at the first meeting of the Sydney Architecture User Group next week (you’ll find the group on Facebook).  So, if you’re in Sydney on Thursday Oct 22nd then head on over the the Grace Hotel, 77 York St, at 6pm and I’ll see you there.  We’ll be in one of the function rooms – just check the board as you enter the hotel to see which one.

For those of you who want to know what I’m talking about – it’s Architecture in the Small and this is the abstract: No matter how good your design or how well the big pieces of your architecture fit together it's the little things that really count. The little things are the things that can take your vision of beauty and either make it a reality or turn it into a thing of nightmares. Richard will talk about what these little things are, the impact they have and, most importantly, what to do about them.