Mock Objects

Google have just announced googlemock, their C++ mocking framework. More details at http://code.google.com/p/googlemock/. It looks like they've done a lot of work.

Labels: mocks in action, news

Steve Freeman at 20:16  permalink 0 comments links to this post

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.

Labels: design, mocks in action, testability

Steve Freeman at 20:30  permalink 2 comments links to this post

Peter Dimov has published his Master's thesis. To quote him:

It is based on Test Driven Development with Mock Objects, hence the focus is on interaction-based testing. I'm introducing the mocking framework CalitkoMocks, which is specially designed to provide a notation for writing tests that can be mapped one-to-one to sequence diagrams. Sequence diagrams are classically used to specify object-oriented software systems, however, it is obvious that just a bunch of diagrams representing individual cases cannot really be regarded as a specification. To address this point, I'm also presenting a few test refactorings which help to extract test scenarios (i.e. generalized test cases), which are more suitable to use as a specification.

He's implemented a mock framework for C++ that's part of Calitko

I especially liked his closing remark

After I drew the diagram corresponding to my test, I decided to try to write a test corresponding one-to-one to the sequence diagram. The sequence diagram showed the calls to my stub objects but my test didn’t (because the implementation invoked them implicitly). I ended up writing smarter versions of my stubs which eventually evolved into mocks. Though I had already read about mocks at that time, I didn’t quite get it what kind of beasts these were. It was only after I reinvented the mock that I truly understood the concept.

Perhaps this is a step on the way to addressing Jason Gorman's concerns.

Labels: design, mocks in action, news, specification

Steve Freeman at 10:19  permalink 0 comments links to this post

Labels: mocks in action, pictures

Steve Freeman at 11:13  permalink 0 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

Steve Freeman at 17:26  permalink 0 comments links to this post