Mock Objects

I'm at Google's Test Automation Conference in New York City (my old stamping ground from the '80's) and so far Mocks have been doing quite well. We had several mentions on his slides from Patric Copeland (Director of QA at Google).

There was also a presentation from Matt Heuser and Sean McMillan, "Examining Interaction-Based testing". I admit I feared a hatchet job but, actually, they presented a very balanced view. They had some good examples of Interaction Testing gone wrong, such as mocking out production code and not writing integration tests. They also pointed out the benefits of using TDD with mocks, including ending up with good code quality statistics implying good maintainability.

The one comment I had on the talk was to de-emphasise use of mocks to speed up unit test runs by mocking external (slow) resources. Our preference is to use mocks within our domain code but to try to write focussed integration tests at the outer boundaries of the system.

Labels: news

Posted by Steve Freeman  20:13 3 comments links to this post

There's been another round of anti-Dependency Injection chatter in the blogsphere, so here we go again. Ayende's done a pretty good job of defending his response to the original posting. The arguments are the same as usual: we don't see why we should change our design just to make it testable. I would like to add a few comments to this round.

• Static factories and the like are still dependencies, just implicit. Instead of making the dependencies clear in the code, so you can set up an object once and then just use it, statics force you to package up a load of hidden references with your class that aren't relevant after instantiation
• I don't go around exposing private features all over the place. I expose the parts that need exposing because they express a relationship with a collaborator
• As an author on the original papers, I resent quotes like

  I wonder if this is a defensive reaction because the authors of the examples don’t want to have to justify making you fundamentally alter your coding habits and re-write all of your existing code just so that you can use their pet objects.

  I'm used to being disagreed with over this technique, but this is a new one on me. Our approach to design has a long and very respectable history. If you're not aware of its roots, then maybe you should alter your coding habits.
• I could do without some of the language, such as

  "The emperor is naked" and you see it.

  and

  Take a look at what people are asking for on the xxMocks forums and the yahoo test-driven group and you will see how every problem that the tool can't solve is actually a design smell. Pragmatic development teams don't believe this anymore.

  like we don't care about shipping reliable and effective systems.

One good thing this episode shows is that there are plenty of people who understand the issues and are prepared to engage.

Labels: design, testability

Posted by Steve Freeman  19:34 7 comments links to this post

At Agile 2007 I chaired an experience report session which had an elegant paper from AtomicObject on their approach to developing code for embdedded systems in C. The relevant bit for this blog is their use of interaction testing.

To make up for the lack of reflection in C, they defined conventions for their header files and wrote Ruby scripts in Rake to generate mocks and link in the right code for the unit tests.

Why did they go to all this trouble? In their words

our mocks revealed that some of the code was making calls it shouldn't have been

The mocks also helped us enforce single responsibility. Whenever the tests for a piece of code got too complicated, we could usually find a good way to break some of the complexity out into another module.

and from the presentation:

Interaction-based testing made tests easier to write and less brittle

It's nice to see the ideas port to a significantly different environment

Labels: mocks in action

Posted by Steve Freeman  17:26 0 comments links to this post