googlemock

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)

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

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?

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

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

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

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

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

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

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

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

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?

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

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?

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.

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!

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

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

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!

Just when you thought it was safe to go back in the water...

Rising to the bait again (to keep the fishy metaphor going), there's yet another discussion of how the ability to hack the runtime changes the world. At one level that's true, but not in this case.

Dependency Injection is not a recent invention that a cabal of TDDers forced on the world, and it's absolutely not something that we came up with just so we could crowbar in our Mock Objects.

The relevant design guideline, named the Law of Demeter ("Strong Suggestion" isn't very catchy) was first described by Karl Lieberherr in 1987! The Mock Object pattern came from people applying their substantial O-O experience to TDD in Java, trying to figure out how best to avoid exposing implementation details in unit tests. One of the critical lessons from Demeter is that objects should have explicit dependencies. It helps to keep them focussed on their responsibilities and, as a result, easier to maintain—and a good way to make dependencies explicit is to pass them in.

Unfortunately, since then the world seems to have filled up with DI frameworks which cloud what should be a coding style discussion. This is not about having to configure every last corner of your application in XML, this is about how objects, or small clusters of them, get to talk to each other.

Roy asks, "[...] do you need DI all over the place, or just in specific places where you know dependencies could be a problem?" Well no—if you have enough foresight to know where those places are. I'm struggling at the moment to test against a framework where everything is helpfully packaged up nice and tight so I can't create an instance of one of its core objects. It's actually well written, but the authors just weren't good enough at prophecy to figure out my particular need. That's why I don't rely just on my intuition, I use the needs of my unit tests to help me figure out where the seams should be. To counter the FUD argument, I have absolutely no problem with saying that I don't want tools that do magic because I need guidance with my code.

As Roy (very politely) concludes, there isn't a high enough proportion of really good code in the world (some of it mine) that we should be in hurry to cut back on techniques such as DI. Just because something has been around for a while doesn't mean it's been superseded, especially in as conventional an environment as .Net.

Avoid mega unit tests

We've just had a posting to the jMock user list that included the following:

I was involved in a project recently where JMock was used quite heavily. Looking back, here's what I found:

1. The unit tests where at times unreadable (no idea what they were doing).
2. Some tests classes would reach 500 lines in addition to inheriting an abstract class which also would have up to 500 lines.
3. Refactoring would lead to massive changes in test code.

I've seen this failure mode on another project I've been helping with, so I think there might be a common pattern.

I don't think any unit test code should get that large, except for unusual circumstances. Unit tests are supposed to focus on at most a few classes and shouldn't need a large amount of set up. What I saw on the other project was enormous amounts of preparation and positioning to get the objects into a state where the expected feature could be exercised. Of course it's hard to understand the point of a test when there's just so much code. If you see this pattern, then I'd suggest that the code (or at least the test code) needs breaking up a bit. On the other hand, integration and acceptance tests that happen to be written using a unit test framework might well be larger.

One thing I need to explore is whether the naive use of interaction-testing is particularly susceptible to this failing, or whether it happens all the time and we're the only ones who get complained to. I am, however, convinced that the emphasis on mainly using Mocks to substitute external systems (some of which I perpetrated myself in the early days) is a deeply bad idea which pushes teams towards the sort of problem described here.