Search

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.

4 Responses to “My Take On JPeck’s TDD Example”

i have another question. how do you handle file naming convention so that people can find the tests easy? my issue with naming classes in such a way is that it’s hard to find the files you are interested in when adding more tests. (aside from just making your change and seeing what breaks)