Saturday, July 10, 2010

Book Review: Growing Object-Oriented Software, Guided by Tests

Recently, I read Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. Amongst excellent discussions of other TDD topics, it sheds a lot of light on good ways to use mock objects.

Personally, I can remember reading Martin Fowler's Mocks Aren't Stubs quite a while ago and concluding that I'd be a "classicist."

Some time later, I started working with mocks as a way to isolate unit tests from "slow" dependencies, such as databases, trying to make them run more quickly. I didn't have much success, though, because I was still writing my tests in a classicist style.

This book helped open my eyes to how the "mockist" style really works, and why it can be a good thing. I absolutely recommend it to any programmer who is doing TDD (or writing unit tests), but who still feels like when it comes to being a mockist, they just don't get it.

I also think a great complement to the book is the video of J. B. Rainsberger's presentation Integration Tests Are A Scam.

As a note on how to read the book, I got a bit bogged down in the middle section, with the worked example. I ended up skipping to the final section and came back to the middle after. Reading it like that worked just fine. I also think it could be interesting to alternate chapters of the middle section with those of the final section.

7 comments:

  1. Thanks for your comments. One point that we make is that we use higher level tests to drive functionality and make sure that our objects actually work together. If you drop the integration tests, then make sure that you have something to replace it.

    ReplyDelete
  2. Good point about the integration tests. I'm definitely not advocating against end-to-end and acceptance tests, as they are defined in GOOS. Nat's "horror story" in the book is great example of how important these are.

    And I'm also not advocating against integration tests as defined in GOOS—tests that check our code works against code we can't change.

    Instead, I think JB's point is that if you're doing a good job with your unit tests, then you should think about whether you really need integration tests, where in his definition, integration tests test that your unit-tested code works against your other unit-tested code—not in an end-to-end or acceptance fashion, but in an object-by-object fashion.

    For example, one "trap" I used to fall into when working with mock objects was that once I had written two unit-tested objects, I felt that I also needed to write an "integration" test to check that they actually did work together in the way the interfaces and mocks defined. But then, there was always a strong temptation not to write the unit tests at all, and instead only write the integration tests. Why test the code at the unit level, if I had to test it again at the integration level anyway? Yes, the unit tests would give me design benefits, but the temptation to "go faster," skipping ahead to what I thought the design should look like, rather than letting it evolve, was often too strong.

    Currently, I think I'm having more luck with with using mocks, making sure to write the appropriate unit tests on each side of a collaboration, but letting the dependency injection framework and end-to-end or acceptance tests take care of making sure the real objects hook up together correctly.

    ReplyDelete
  3. Nice review. I think that might be good advice to skip the middle section, at least initially. I should take your approach when Im due to reread this again shortly.

    The first and last parts are absolute gold. But I feel for the authors trying to express a progressive worked example in book form in the middle section. Its too easy to forget the context as you are reading it. Perhaps a book just isnt the right way to communicate this?

    I think this is a great book none the less.

    ReplyDelete
  4. Ross,

    Well, a book probably isn't the best way to communicate a worked example—probably the best way would be pairing with Steve or Nat :-)

    But given that might not happen, I'm having trouble thinking of a better way than what they do in the book. Maybe something like the pairwith.us screencasts?

    In general, I have difficulty with long code examples in books. I think you're right that it's easy to forget the context. But I also assume given that many books use this format—books that other people seem to like a lot—some people must get along better with it than I do.

    In GOOS, I'm glad the middle section is there. I felt I got a lot out of it when I went back to it after reading the last section.

    So, my advice is just that if, like me, long code samples don't float your boat, or you find it difficult to get through the middle, try skipping to the last section and coming back to it. Because I agree that the first and last parts are gold, and I'd hate for people to miss them. Plus, I felt I got a lot more from the middle section after reading the last.

    ReplyDelete
  5. The technique total committed football competitors will receive free fifa 16 coins together with factors.

    ReplyDelete
  6. I didn't have much success, though, because I was still writing my tests in a classicist style. https://wadeprogram.com/features.html

    ReplyDelete
  7. “it’s always a good idea”! If you don’t know how to start, just visit http://777extraslot.com and stop to be just a reader!

    ReplyDelete