There was a brief discussion on the JMock mailing list recently where we helped out a new user. In the process, we noticed that he was mocking Java Set, which we tend to avoid, because it's not a type that we own—it's not in the domain of the problem we're trying to solve. The way I put it was,

We see a lot of people using, for example, List<House> when what they actually mean is Street. We try to use types we own that represent concepts in the domain, rather than built-in or library types which we keep for implementing these domain types. If the domain types are defined in terms of roles, then they're often appropriate for mocking.

Isiah followed up with an old post of his own.

I think we have a satisfied customer:

Thank you Steve and Isiah, I think I just took a large step in the world of TDD.

It's nice when that happens...

Are we really doomed to another generation of procedural code masquerading as objects?

Roy Osherove has come out against "mocking" in favour of "isolating". One reading of his point is that mocking is just too hard for the bulk of the programmers he sees. Perhaps that's true (the others developers who discovered the technique are all very good) but I hope not (either that or I should increase my rates). And I'm pleased to see Oren, for one, has responded.

Roy addresses important issues which we need to think about, but we shouldn't pitch the whole industry at the level of its least skilled members; I've spent too much of my life cleaning up code that should never have been written in the first place. In the meantime, if his staff don't understand basic Object-Orientation, then that's what he should be teaching first, with a sprinkling of acceptance testing on top for regression.

Reading the post and its comments again, I see repeated "Doctor, it hurts when I do that" moments. Roy's response is to back off interaction testing, but that misses the experience and insight that led us into this situation in the first place. My call is that, like Object-Orientation, the technique is widely misunderstood, which is why the same objections keep coming back. This isn't a comfortable position.

To take the most obvious example, as Roy says himself, record/replay just doesn't cut it. That's why we've never supported it. It's easy to start with, but then my experience is that it encourages unmaintainable tests. It focusses the language of a test on the accident of the current implementation, rather than on the significant relationships between objects. It also encourages asserting every interaction, which leads to just the sort of problem that everyone complains about, brittle overspecified tests. That's why we don't do it, we only assert interactions that can affect the world around the object under test and stub the rest.

The other disaster (yes, I think record/replay has been a disaster) was our early attempt to mock the entire Java libraries. Apart from being unrealistic, it sent entirely the wrong message, emphasising isolating from databases over guiding the design. Later, Joe Walnes coined the notion of "Only Mock types you own", which really helped some people get the idea.

As someone posted somewhere in this exchange, TDD will punish you if you don't understand design. I'd argue that that's what it's for, and that it's essential to listen to what the tests are saying rather than turning down the volume.

We've cut down the introduction and moved some of the material into a new section, Examining the Process. Check it out and let us know what you think. More content to follow soon.

We've posted another episode from our long worked example.

At the start of every test run, we need our test script to start up the Openfire server, create accounts for the Sniper and Auction, and then run the tests. Each test will start instances of the application and fake auction and test their communication through the server.

We've also made some changes in response to comments on the discussion list

We've posted the first couple of chapters of the long worked example from our book, Growing Object Oriented Software Guided by Tests. It's work in progress: some of the diagrams have not been finished quite yet. As ever, feedback is welcome via the discussion group.

We have put a new chapter of the book online: Chapter 5. An Introduction to the Tools.

What happened to chapter 4? We've moved some chapters around after reading people's comments in the discussion group and will publish chapter 4 as soon as we've finished it and polished it up. We'll put the new table of contents up ASAP.

You can give comments and feedback via the discussion group or as blog comments.

Update: explained why we are only giving a cursory introduction to the tools. Improve explanation of why we chose JUnit and include where you can download it from.