Mocks driving an SRP(*) design

Earlier this month, there was an interesting discussion on the Test-Driven Development list. avinap77 was reflecting on test-driving his code using mocks. Later on, he posted this to the list.

[...] I also realized that an expectation is more than just expecting a method to be invoked - it's also the paramaters that are sent to it and what happens with the method's result. In the example, my class needed to invoke a getCustomerDetails() method on the IDatabase collabroator, send it the appropriate ID as a paramater, and then send the resulting customerName to another collaborator (the IHtmlFormatter), and finally return the formatter's result - so this is in fact testing four different operations. I also found that these "smells" turn up pretty early - as soon as I'm trying to write a test with too many interactions, that's the immediate "red light" that the class has too many responsibilities, and I immediately start writing a more focused test which introduces more focused responsibilities represented as narrow interfaces (such as replacing the IDataBase with the INameProvider in the example). This is opposed to some state-based "baby steps" examples I've seen where the splitting into responsibilities might come later during refactoring. Do you find this too when using mocks/interactions?

This is the experience we keep trying to convey when promoting Mock Objects as a technique, with limited success. It forces you to think about what the pieces should be and where they go. One of the real hurdles to working well with Mocks is to realise that the point is not to reproduce interactions with existing types, but to force the discovery of new types. (*) SRP Single Responsibility Principle

What happened to the mockobjects.com library?

We recently had an inquiry about our old mockobjects.com library. It's still in cvs at the sourceforge project but, essentially, it's dormant. These days, there are better alternatives for Java, like EasyMock and (ahem) our own jMock.

Like a Fire Drill

David Saff has come up with an entertaining metaphor for using mock objects: the School Fire Drill. There are a couple of ways to test that your pupils are prepared for a fire. You can set light to the school: the alarm will go off, everyone will troop outside, and the fire brigade will turn up and douse the building in water. Now you've tested the whole system so you can be sure that everything works. Of course, you'll have also lost your job but that's another matter. Alternatively, you can coordinate with the fire station and just set off the alarm. You can check that the pupils don't rush the exits and that everyone is accounted for. You can try a couple of different assembly points without much cost. You can keep your job. The rest of the system can be tested separately: you can check the alarm on Wednesdays at 11:00, and the fire brigade will have its own drills. Every once in a while, some building really will catch fire which will confirm that things work end-to-end. (In software, of course, you can run functional tests more predictably).

Normal service will be resumed.

This is a new implementation of the mockobjects.com site. We'll port the material from the old site and add new content about working with Mock Objects.