Mock Objects

A Brief History of Mock Objects

noreply@blogger.com (Steve Freeman) — Tue, 08 Sep 2009 09:05:00 +0000

As an afterword to the book, we had Tim Mackinnon write up a piece on how we got here. In compensation for having been so quiet for a while, here's that chapter.

Introduction

The ideas and concepts behind mock objects didn't materialise in a single day. There's a long history of experimentation, discussion, and collaboration between many different developers who have taken the seed of an idea and grown it into something more profound. The final result should help you with your software development; but the background story of “The Making of Mock Objects” is also interesting—and a testament to the dedication of the people involved. I hope revisiting this history will inspire you too to challenge your thoughts on what is possible and to experiment with new practices.

Origins

The story began on a roundabout near Archway station in London in late 1999. That evening, several members of a London-based software architecture group met to discuss topical issues in software. The discussion turned to experiences with Agile Software Development and I mentioned the impact that writing tests seemed to be having on our code. This was before the first Extreme Programming book had been published, and teams like ours were still exploring how to do test-driven development—including what constituted a good test. In particular, I had noticed a tendency to add “getter” methods to our objects to facilitate testing. This felt wrong, since it could be seen as violating object-oriented principles, so I was interested in the thoughts of the other members. The conversation was quite lively—mainly centering on the tension between pragmatism in testing and pure object-oriented design. We also had a recent example of a colleague, Oli Bye, stubbing out the Java Servlet API for testing a web application without a server.

I particularly remember from that evening a crude diagram of an onion and its metaphor of the many layers of software, along with the mantra “No Getters! Period!” The discussion revolved around how to safely peel back and test layers of that onion without impacting its design. The solution was to focus on the composition of software components (the group had discussed Brad Cox's ideas on software components many times before). It was an interesting collision of opinions, and the emphasis on composition—now referred to as dependency injection—gave us a technique for eliminating the getters we were “pragmatically” adding to objects so we could write tests for them.

The following day, our small team at Connextra started putting the idea into practice. We removed the getters from sections of our code and used a compositional strategy by adding constructors that took the objects we wanted to test via getters as parameters. At first this felt cumbersome, and our two recent graduate recruits were not convinced. I, however, had a Smalltalk background, so to me the idea of composition and delegation felt right. Enforcing a “no getters” rule seemed like a way to achieve a more object-oriented feeling in the Java language we were using.

We stuck to it for several days and started to see some patterns emerging. More of our conversations were about expecting things to happen between our objects, and we frequently had variables with names like expectedURL and expectedServiceName in our injected objects. On the other hand, when our tests failed we were tired of stepping through in a debugger to see what went wrong. We started adding variables with names like actualURL and actualServiceName to allow the injected test objects to throw exceptions with helpful messages. Printing the expected and actual values side-by-side showed us immediately what the problem was.

Over the course of several weeks we refactored these ideas into a group of classes: ExpectationValue for single values, ExpectationList for multiple values in a particular order, and ExpectationSet for unique values in any order. Later, Tung Mac also added ExpectationCounter for situations where we didn't want to specify explicit values but just count the number of calls. It started to feel as if something interesting was happening, but it seemed so obvious to me that there wasn't really much to describe. One afternoon, Peter Marks decided that we should come up with name for what we were doing—so we could at least package the code—and, after a few suggestions, proposed “mock.” We could use it both as a noun and a verb, and it refactored nicely into our code, so we adopted it.

Spreading the Word

Around this time, we also started the London Extreme Tuesday Club (XTC) to share experiences of Extreme Programming with other teams. During one meeting, I described our refactoring experiments and explained that I felt that it helped our junior developers write better object-oriented code. I finished the story by saying, “But this is such an obvious technique that I'm sure most people do it eventually anyway.” Steve pointed out that the most obvious things aren't always so obvious and are usually difficult to describe. He thought this could make a great paper if we could sort the wood from the trees, so we decided to collaborate with another XTC member (Philip Craig) and write something for the XP2000 conference. If nothing else, we wanted to go to Sardinia.

We began to pick apart the ideas and give them a consistent set of names, studying real code examples to understand the essence of the technique. We backported new concepts we discovered to the original Connextra codebase to validate their effectiveness. This was an exciting time and I recall that it took many late nights to refine our ideas—although we were still struggling to come up with an accurate “elevator pitch” for mock objects. We knew what it felt like when using them to drive great code, but describing this experience to other developers who weren't part of the XTC was still challenging.

The XP2000 paper and the initial mock objects library had a mixed reception—for some it was revolutionary, for others it was unnecessary overhead. In retrospect, the fact that Java didn’t have good reflection when we started meant that many of the steps were manual, or augmented with code generation tools. This turned people off—they couldn't separate the idea from the implementation.

Another Generation

The story continues when Nat Pryce took the ideas and implemented them in Ruby. He exploited Ruby's reflection to write expectations directly into the test as blocks. Influenced by his PhD work on protocols between components, his library changed the emphasis from asserting parameter values to asserting messages sent between objects. Nat then ported his implementation to Java, using the new Proxy type in Java 1.3 and defining expectations with “constraint” objects. When Nat showed us this work, it immediately clicked. He donated his library to the mock objects project and visited the Connextra offices where we worked together to add features that the Connextra developers needed.

With Nat in the office where mock objects were being used constantly, we were driven to use his improvements to provide more descriptive failure messages. We had seen our developers getting bogged down when the reason for a test failure was not obvious enough (later, we observed that this was often a hint that an object had too many responsibilities). Now, constraints allowed us to write tests that were more expressive and provided better failure diagnostics, as the constraint objects could explain what went wrong. For example, a failure on a stringBegins constraint could produce a message like:

Expected a string parameter beginning with "http"
 but was called with a value of "ftp.domain.com"

We released the new improved version of Nat's library under the name Dynamock.

As we improved the library, more programmers started using it, which introduced new requirements. We started adding more and more options to the API until, eventually, it became too complicated to maintain—especially as we had to support multiple versions of Java. Meanwhile, Steve tired of the the duplication in the syntax required to set up expectations, so he introduced a version of a Smalltalk cascade—multiple calls to the same object.

Then Steve noticed that in a statically typed language like Java, a cascade could return a chain of interfaces to control when methods are made available to the caller—in effect, we could use types to encode a workflow. Steve also wanted to improve the programming experience by guiding the new generation of IDEs to prompt with the “right” completion options. Over the course of a year, Steve and Nat, with much input from the rest of us, pushed the idea hard to produce jMock, an expressive API over our original Dynamock framework. This was also ported to C# as NMock. At some point in this process, they realized that they were actually writing a language in Java which could be used to write expectations; they wrote this up later in an OOPLSA paper.

Consolidation

Through our experience in Connextra and other companies, and through giving many presentations, we improved our understanding and communication of the ideas of mock objects. Steve (inspired by some of the early lean software material) coined the term “needs-driven development,” and Joe Walnes, another colleague, drew a nice visualisation of islands of objects communicating with each other. Joe also had the insight of using mock objects to drive the design of interfaces between objects. At the time, we were struggling to promote the idea of using mock objects as a design tool; many people (including some authors) saw it only as a technique for speeding up unit tests. Joe cut through all the conceptual barriers with his simple heuristic of “Only mock types you own.”

We took all these ideas and wrote a second conference paper, “Mock Roles not Objects”. Our initial description had focused too much on implementation, whereas the critical idea was that the technique emphasizes the roles that objects play for each other. When developers are using mock objects well, I observe them drawing diagrams of what they want to test, or using CRC cards to roleplay relationships“these then translate nicely into mock objects and tests that drive the required code. Since then, Nat and Steve have reworked jMock to produce jMock2, and Joe has extracted constraints into the Hamcrest library (now adopted by JUnit). There’s also now a wide selection of mock object libraries, in many different languages.

The results have been worth the effort. I think we can finally say that there is now a well-documented and polished technique that helps you write better software. From those humble “no getters” beginnings, this book summarizes years of experience from all of us who have collaborated, and adds Steve and Nat's language expertise and careful attention to detail to produce something that is greater than the sum of its parts.

Book: The Worst is Over

noreply@blogger.com (Steve Freeman) — Wed, 12 Aug 2009 08:51:00 +0000

We've been silent for a while, getting on with writing.

The news is that we're done with copy editing and now it's into the presentation work such as formatting, proofing, and indexing. We're even up on Amazon, although our editor says that we should be out before November.

Using Mocks and Tests to Design Role-Based Objects

noreply@blogger.com (Steve Freeman) — Thu, 11 Jun 2009 20:24:00 +0000

Isaiah Perumalla has had a paper published by MSDN. They trimmed it a bit, so we're hosting the original here.

Another update to the book

noreply@blogger.com (Steve Freeman) — Thu, 21 May 2009 21:30:00 +0000

We've gone very quiet for a while because we've been busy writing (and rewriting, and rewriting). We've reworked some of the example, and done some substantial clean-up in parts III and IV. Let us know on the list what you think.

Book. More and more

noreply@blogger.com (Steve Freeman) — Thu, 02 Apr 2009 21:43:00 +0000

As the deadlines approach… We've published new chapters: another chapter in the example on handling failures, one on our approach to Object-Oriented design and one on how that relates to Mock Objects, and one on testing asynchronous code. Enjoy—and comment.

Book. More chapters posted

noreply@blogger.com (Steve Freeman) — Fri, 27 Mar 2009 11:05:00 +0000

We've been quiet for a while because we've been trying to make progress with the book. To let you know how we're doing, we've just posted some more draft chapters: there's more from the extended example, one on how to maintain ongoing TDD, and one on how to cope with threading. As always comments welcome, and join the discussion list.

googlemock

noreply@blogger.com (Steve Freeman) — Sat, 13 Dec 2008 20:16:00 +0000

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.

Only mock types you own (revisited)

noreply@blogger.com (Steve Freeman) — Thu, 27 Nov 2008 17:07:00 +0000

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...

More example, reworking the process

noreply@blogger.com (Steve Freeman) — Thu, 27 Nov 2008 17:03:00 +0000

We've posted some more chapters from the long worked example. We've also been reworking the material on the Process of TDD. Take a look, and comments are always welcome.

TDD. Killing the messenger?

noreply@blogger.com (Steve Freeman) — Thu, 25 Sep 2008 19:30:00 +0000

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.

Reordering chapters

noreply@blogger.com (Steve Freeman) — Tue, 23 Sep 2008 07:44:00 +0000

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.

Chapter 9. Passing the First Test

noreply@blogger.com (Steve Freeman) — Thu, 04 Sep 2008 07:03:00 +0000

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

Long Worked Example

noreply@blogger.com (Nat Pryce) — Thu, 28 Aug 2008 09:44:00 +0000

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.

New Table of Contents Online

noreply@blogger.com (Nat Pryce) — Thu, 21 Aug 2008 22:03:00 +0000

We've posted the new Table of Contents. From now on, we'll update this as we put chapters online and shuffle content about.

Chapter 5. An Introduction to the Tools

noreply@blogger.com (Nat Pryce) — Thu, 21 Aug 2008 12:59:00 +0000

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.

Chapter 3. Kick-Starting the Test-Driven Cycle

noreply@blogger.com (Nat Pryce) — Wed, 06 Aug 2008 10:52:00 +0000

We have put a new chapter of the book online: Chapter 3. Kick-Starting the Test-Driven Cycle.

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

Update: added a sidebar about kick-starting "brownfield" development.

Chapter 2. Test-Driven Development with Objects

noreply@blogger.com (Steve Freeman) — Fri, 25 Jul 2008 11:50:00 +0000

We are now publishing chapters of our book, Growing Object-Oriented Software Guided by Tests in a separate section of the site. We will publish news about new content in the blog but will not include the entire contents of each chapter as blog posts.

We have updated Chapter 2, Test-Driven Development with Objects in response to feedback from blog comments and the discussion group and improved some of the diagrams. More comments are always welcome.

Book Discussion Group

noreply@blogger.com (Nat Pryce) — Wed, 16 Jul 2008 12:13:00 +0000

We have created a Yahoo Group to host feedback and discussion about the book we're working on. If you have any feedback we'd love to hear from you.

Chapter 1. What's the point of Test-Driven Development?

noreply@blogger.com (Steve Freeman) — Mon, 14 Jul 2008 20:34:00 +0000

We have updated Chapter 1, What's the Point of Test-Driven Development? in response to feedback from blog comments and the discussion group and improved some of the diagrams. More comments are always welcome.

Growing Object-Oriented Software, Guided by Tests

noreply@blogger.com (Steve Freeman) — Sun, 13 Jul 2008 22:49:00 +0000

We have been working for some time on a book about our approach to developing software test-first. We've been working at it long enough that we though it was time to start putting up some material to get some feedback which, after all, is a technique we go on and on about. We'll start with chapters in HTML, then add some PDFs on the side as the material grows.

Here's our opening.

A Deceptively Simple Idea

Test-Driven Development (TDD) is a deceptively simple idea: write the tests for your code before writing the code itself. We say “deceptively simple” because this reversal fundamentally changes the role that testing plays in the development process and challenges the industry's assumptions about what testing is for. Testing is no longer just about keeping defects from the users, instead it's about helping the team to understand the features that the users need and to deliver those features reliably and predictably. When followed to its conclusions, TDD radically changes the way we develop software and, in our experience, dramatically improves the quality of the systems we build, in particular their reliability and their flexibility in response to new requirements.

Test-Driven Development is widely used in “agile” software development methods. It is a core practice of Extreme Programming (XP) [Beck99], is recommended by Crystal Clear [Cockburn04] and often used in Scrum™ [SB01] projects. If you're going to work on an agile project, you will probably use TDD. We've used TDD on every agile project we've been involved in and have snuck the practises in to non-agile projects. We've even found it useful in pure R&D projects that explore possibilities rather than meet customer needs and so have no need of the customer-facing project management practices of agile methods.

More...

The Table of Contents links to the published chapters.

Feedback and Discussion

If you want to give us feedback on what we've written so far and see what other people think about it, please join the discussion group.

Public training courses?

noreply@blogger.com (Steve Freeman) — Thu, 05 Jun 2008 14:43:00 +0000

We've had a couple of inquiries about whether we will be running our training course publicly. We hadn't planned to, but perhaps we should. We propose to run a two-day course priced at £1100 if booked less than 4 weeks ahead of the teach date, with a discount to £800 if booked earlier (plus UK VAT). The most obvious location is London (UK).

If you think you might be interested (no commitment implied), please drop us an email at public.course@mockobjects.com with this information:

Name: 
London is acceptable:
Preferred other location:
Preferred month for teach date:
Possible number of attendees:
Coding experience (years): 
TDD experience (years):
Contact email:
Contact phone:

We'll see if we can work something out

In case you're feeling nervous, whatever details we receive will be used only by us just to coordinate a course. We won't hassle you or pass them on to anyone else.

Talk at London Geek Night.

noreply@blogger.com (Steve Freeman) — Fri, 30 May 2008 09:47:00 +0000

Nat and I gave a talk at the most recent London Geek Night. It was an introduction to our approach to Test-Driven Development, incidentally making the point that some of the state- vs. interaction-based TDD wars are a bit specious; it's a matter of picking the right tool for the job. We had a good crowd and some useful questions. Afterwards, there was a Code Dojo in which Nat took part while I got stuck at the back talking to people. Thanks again to our hosts for an interesting evening.

We've uploaded the slides with notes. The format's a little odd because we used the toolchain we use for our courses, but the material's all there.

There are couple of other relevant links. Nils Haugen has a nice talk he did on Improving Test Maintainability, which is about making sure the tests make sense. Our interest is more in the stage after that, which is about listening to what the tests are telling you about the design of your code.

Learn from the source!

noreply@blogger.com (Steve Freeman) — Fri, 23 May 2008 16:37:00 +0000

Nat, Romilly Cocking, and I are now open for business for training. We have a course on Test-Driven Development that reflects nearly a decade of experience writing tests first (that's 30 years in parallel). We also have significant experience in training, Romilly has a couple of decades on his own, and Nat and I have taught commercially and at two of the top CS departments in the country.

The course teaches the practice of Test-Driven Development, based on a solid understanding of Object-Oriented design, and with a strong emphasis on making tests expressive and maintainable. We also make a point of exploring how unit tests can be used to drive the design of the code, not just protect it.

The content is modular, so we can adjust it to match the needs of the participants. The full-length course is three busy days, and we've taught versions that are a half-day and whole-day long.

We teach the course using jUnit4, Hamcrest, and (of course) jMock2. Talk to us if you want something different.

For more information, contact us at: training@mockobjects.com

Here's what some attendees liked about the course:

“The practical exposure to a better way of testing”

“Practical lab work, real-world concrete examples, Expert lecturers!”

“Chance to make mistakes and learn. Exposure to new technology.”

“A very good whole picture view of TDD and mocks”

“Interaction and explanation of course materials particularly through the exercises.”

Another round in the testability debate

noreply@blogger.com (Steve Freeman) — Sat, 08 Mar 2008 09:52:00 +0000

This time a posting from Mark Seemann has raised a slew of comments.

One of them is a note from Colin Jack about the annoyance of producing interface/implementation pairs all the time. My first response is that that sounds to me a bit like a problem with style. Maybe it's just wordplay, but usually I don't extract interfaces from classes, I implement interfaces that I've already discovered in some previous test.

My second response is to wonder how much this is a tools issue. I don't believe there's anything in the .Net world that yet matches the responsiveness of the usual Java IDE's. It makes a difference as to what's plausible. I remember the huge shift in perception when first VisualAge for Java and then JetBrains' Idea came out. In retrospect, I always spent more on time on rework than many people I worked with ¹ but it sure took a lot more time in emacs (and I was pretty good at it), even if I was working in a better language.

1) which is not to say who was right, I'm just wired that way...

New Tutorial at QCon

noreply@blogger.com (Steve Freeman) — Tue, 12 Feb 2008 10:03:00 +0000

On Tuesday 11th March, at QCon London, Romilly Cocking and I will be running a new tutorial we're developing with Nat Pryce on Test-Driven Development with Mock Objects following on from a successful first run at the last XpDay. Sign up soon!