My Take On JPeck’s TDD Example

I had some spare time today, so I caught up on my friend James’ blog. He recently posted a real-world example of TDD taken, I assume, from his real-world job of developing software for a bank.

In the comments section of this particular post, someone named Darren made a case for using interfaces and mocks in the design of the tests and the resulting software. James stated that he would probably try that approach next. Well, the original post is about one month old now and I happen to have T.A.D.D. (Technical Attention Deficit Disorder). So, I’ve posted my version of James’ real-world TDD example. A few comments about my design:

• I changed the design of the HumanResourcesService. I renamed it to “IEmployeeService”, extracted and renamed the methods and created a criteria-based lookup.
• I renamed the “HumanResources” class to “EmployeeManager” and made it work against the IEmployeeService abstraction.
• I exposed the GetEmployeeById as a public method in EmployeeManager. I figured this would be a good thing to provide consumers.
• I used Rhino Mocks and SpecUnit as the mocking and TDD frameworks, respectfully.
• I generated a report (HR.Specs.html) showing the different specifications the test code is exercising. The report looks nice, but to get it I had to use underscores in the spec class names (yuck). Was it worth it? Probably.

In general, I tried to follow the AAA (Arrange, Act, Assert) pattern in the spec code. I’ve included James’ very-slightly-modified code in the solution for reference (I renamed a couple of variables I found offensive). Click here to download the code. Rename it to a .zip file to access the contents.