Comments on programmer.grrl: Book Review: Growing Object-Oriented Software, Gui...

Ross, Well, a book probably isn't the best wa...

2010-07-18T14:10:41.843+01:00

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.

Nice review. I think that might be good advice to ...

2010-07-11T15:02:21.424+01:00

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.

Good point about the integration tests. I'm de...

2010-07-11T11:41:34.792+01:00

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.

Thanks for your comments. One point that we make i...

2010-07-10T10:15:32.083+01:00

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.