Effectively teaching test-first: Make it go green!

When you’re producing quality code using Test Driven Development you’re likely to use either the test first or test last approach (or more likely; a mix of those). Test first means that you write your test before you implement the method you’re testing (i.e. the functionality). If you’re following the test last mantra, you would implement the functionality first and then add test(s) to verify the behavior of the method. Strictly speaking, the latter approach will IMO not be a test driven development. If you want your tests to drive the architecture of your application, you should definitely go for the test first. It’s not that the test last won’t give you a testable application, it’s just that writing the test first makes it far easier to get your test actually be an unit test and not an integration test.

"I'm trying to free your mind, Neo. But I can only show you the door. You're the one that has to walk through it."

I must confess; I felt that writing tests first was really hard in the beginning. Before you start mastering the art of unit testing, you cannot really write the tests first unless you get some good guidance doing it. I’ve been doing TDD for a while now and I feel quite confident about it, and so I try to teach my team members the same philosophy. And the method I found that really helped getting them on the right track was to just sit down and do some pair-programming with them. We start out the session with me behind the keyboard. According to XP-ists the time between switching the roles of the driver (the one typing on the keyboard) and the observer (the one reviewing the code) should be around 30 minutes or so. But what I really find effective when it comes to teaching test first, is to do the switching after I’ve written the unit test. When writing the unit test itself, I do this while thinking out loud and discussing the code with my fellow dev. That way I practically show him/her how I think when I write the test and (s)he will have a good starting point for implementing the functionality. After I’ve finished writing the test, I just hand over the keyboard saying; “Make it go green!”

Would this method work in all circumstances? Certainly not! If (s)he was totally new to testing and I were to give an intro to unit testing, I’d probably choose another way. I’d probably show how to do some integration or unit testing on existing code before introducing the test first approach. Doing this exercise with someone who’s never seen a unit test before would probably be too much to grasp at once. When I’m coding the unit test in the Make-It-Go-Green-method I often have to use mocks to isolate the method under test and to introduce mocking to developers who have never seen unit test before will probably not be a good idea. In that case I’d rather let them do some integration tests before teaching them some real TDD. But maybe that’s just me…

MemberAccessException

Exceptions are meant for those exceptional conditions that never should happened during your programs lifetime, but that you cannot guarantee won't happen. As you might expect from this statement, I'm not a big fan of sprinkling the code with unnecessary exception throws. I find it more useful to test those exceptional cases using unit and integration tests.

Anyway; while studying the source code from the excellent CodeProject article "NHibernate Best Practices with ASP.NET" by Billy McCafferty, I came across this quite interesting use of MemberAccessException;

public IOrderDao OrderDao
{
  get
  {
    if (orderDao == null) {
      throw new MemberAccessException("OrderDao has not yet been initialized");
    }
    return orderDao;
  }
  set { orderDao = value; }
}

If it were me coding this, I’d probably just throw the far more general ApplicationException or something (if I'd throw it all, mind my words in the intro to this post). But I definitely see that the MemberAccessException would be a lot better fit for this exceptional case.

Excellent blogposts on DDD and NHibernate

I'm in the process of setting up NHibernate on a new project and we've decided to try to let the domain model drive our development. Meaning; we're trying to follow the Domain Driven Design mindset. And as I'm quite new to both NHibernate and DDD, reading the 9-parts series called "A Journey with Domain Driven Design (and NHibernate)" by Ben Scheirman really gave me a good start. But unfortunately there's no summary post for his article series, so for my own reference I'll add it here;

Part 1: Intro and project structure: "In the first few articles, we will see how to start projects using NHibernate, go over some basic topics, and then get progressively more complex as we explore the many features of the ORM tool."

Part 2: Domain model: "This time I am going to start off creating a pet project to demonstrate how to implement these ideas. First we’ll implement a simple domain model to support our features. We will combine these with unit tests to verify behavior."

Part 3: Unit testing: "When testing, whether you practice test-driven development (TDD) or not, it is important that your tests and your code follow each other closely. (...) I’m not a TDD purist, but I try to write the tests first to let the consumer (the calling code) drive the design."

Part 4: Unit testing with transactions: "Let’s get on with the more interesting tests. Another thing I’d like to note is that, the tests here pass, but only after I write the appropriate code in the model to satisfy the test. I am purposefully omitting the domain model code at this time because it is unimportant. You should be able to understand what the code does without looking inside the class. "

Part 5: Database schema and NHibernate config/initialization (ISessionFactory, ISession): "Let’s create a database structure to support persistence of our domain model."

Part 6: NHibernate mapping: "We’ll dive in deeper with NHibernate and mapping in this article."

Part 7: NHibernate mapping with associations/relations: "We introduced some simple mapping concepts, and this time we’ll dig in a bit deeper."

Part 8: NHibernate split mapping files, building a Repository and saving to the database: "We left off last time with our first association mapped and tested. Let’s dig in a bit deeper with NHibernate mapping.(...) Repository takes advantage of generics to avoid a lot of duplicate code. This is a quick implementation of the Repository pattern (...)"

Part 9: Higher level tests: "In this article, part 9 of the series, we’re going to wrap up our initial feature list and focus on building a user-interface for our video store, named Videocracy."