Allow me to invite you to XP 2008 in Limerick, Ireland on June 11, 2008 at 2 PM local time to join me for Test-Driven Enterprise Code, my long-running tutorial aimed at programmers who want to practise test-driven development in the complicated world of platforms, frameworks, libraries, and more. Stay tuned to this channel for presentation slides, and possibly more.

Discuss

It’s nice to see that nearly five years after I started writing JUnit Recipes, people continue to read and review it. I imagined it would have become obsolete by now, especially with the proliferation of Java 5, Java 6 and JUnit 4.

The review ends with “If you use JUnit as your test tool and if you do any of the ‘things’ covered in the contents list of recipes then I recommend getting hold of this book.” I appreciate it.

Discuss

I recently came across this question on the testdrivendevelopment Yahoo! group.

Hi everyone,

I’d like some advice/opinions on how to test some existing code. It’s a web application using Spring and struts.

I have a class called the ProcessedFilesManager which contains a number of methods used by Struts Action classes. This manager communicates with five different DAOs to get the information that some of the Struts actions are interested in. Now, I want to test this manager class (ProcessedFilesManager). The way I’ve started doing it is stubbing up each of the five DAOs, however, this is proving to be quite painful. I didn’t want to use a mocking approach, nor did I want to use a DB solution like Hypersonic, but now I’m open to suggestions.

Seeing as there a number of approaches I could use, what do you think would be best for this situation?

It feels wrong to stub the DAOs because what if I’m introducing behaviour in there that differs from the actual DAOs? My tests will not be accurate.

Any advice/comments would be much appreciated.

[Read the thread]

I used to have this fear, and I do something now that has eliminated that fear.

When I stub a DAO method, I make an assumption about what that DAO method does. I used to be worried about making the wrong assumption, but now I have a contract test for the DAO interface that tests for the assumption I’m making in my Service test. The contract test gives me confidence that any implementation of the DAO method passes the same tests, so every implementation of that DAO method behaves the way I assume it does. Once I have this, I feel comfortable stubbing that DAO method that way in a Service test.

A contract test is a test for an interface. I describe contract tests in some detail in JUnit Recipes, recipe 2.6, although back then I called them “abstract test cases” because I hadn’t yet discovered the better name “contract test”. If you prefer, I’ve provided a diagram showing some contract tests for a typical DAO class.

Since classes inherit methods from their superclasses, the Hibernate Customer DAO Test will inherit the contract tests from its superclass, as will the JDBC Customer DAO Test. This means that each implementation has to pass not only its own tests (like testClosesSession() or testClosesResultSet()) but also the tests inherited from Customer DAO Contract Test Template. (I call it a “template” because it plays the role of template in the Template Method design pattern.) When you test-drive a new implementation of Customer DAO, simply make the new test extend the contract test template and you’ll automatically inherit its contract tests. This way, I have confidence that any implementation of Customer DAO behaves the way I’d expect any Customer DAO to behave.

Returning to our example, these contract tests give me confidence to stub the DAO when I test-drive the Service, and that confidence brings with it a happy side effect. I am confident that findAllWithPendingOrders() only returns customers with pending orders, so I don’t have to worry about that issue at all when I design the Service that reports all customers with pending orders. Now that I notice it, Report All Customers With Pending Orders Service is really just a Report on Customers Service that needs a Customer Filter, which could be a Pending Orders Customer Filter. I don’t think I would have felt comfortable with this level of generalization if I weren’t so confident in the way I’ve separated the responsibilities.

The next time you want to avoid stubbing a method because you’re worried you’ll make a wrong assumption about what the method does, try writing enough contract tests to give you the confidence you need. I think you’ll like the results.

Discuss

I want to be clear: I have not yet read Next Generation Java Testing, Cédric Beust’s book about TestNG. I am not writing this to make a comment about the quality of Cédric’s book one way or the other; however, the first reader’s comment put me in mind of a conversation I had at Better Software’s Agile Development Practices conference about TestNG v. JUnit, Cédric v. J. B., and all that good stuff. In that conversation I reached what I felt at the time was an insightful conclusion. This might be obvious to some, but it’s significant to me. I now firmly believe I know the source of our differences, between JUnit and TestNG, between Cédric and me.

TestNG is about testing. JUnit is about design.

Once I reached this conclusion, any notion of one tool being better than the other has absolutely no relevance. A while ago, I proposed that TestNG and JUnit were complementary in the sense that TestNG was more about end-to-end testing and JUnit was more about object testing. I now see that as a false division. If you write tests to do primarily validation or verification, then maybe you should use TestNG, because its features fit better for a testing focus. If you write tests in order to explore design ideas concretely, then maybe you should use JUnit, because its features fit better for a design focus. (Of course, since BDD is TDD done well with less cognitive load to the learner, Java people doing BDD could use JUnit if they didn’t mind calling them “fixtures” and “tests”.)

Discuss

This is just a reminder that I am presenting Refactoring: Where Do I Start? at Better Software’s Agile Development Practices conference in Orlando on December 6 at 10:00 AM. I’ll spend about 20 minutes talking about refactoring, about 40 minutes doing it and about 30 minutes answering your questions. If you’re unsure how to refactor code, how to begin to learn about refactoring or which part of your system to attack first, this presentation is for you. I hope you see you there.

Discuss