Disclosure: Manning Publications is a sponsor of the Chicago Sencha User Group, and they provide free copies of of their books as giveaways for our monthly meetings. I have not been paid for this review, although I did receive this book for free.
Over the past year or so I’ve probably read a dozen technical books. Technical books are very curious in that some are really good and others are simply terrible – there’s not many that fall in-between, and that’s often because these books involve specific topics and rely on code-heavy content.
Specification By Example is the first technical book I have read in a long time that has no code. It’s an interesting dichotomy… but one that I think works really well in this case. In fact, that’s ultimately the point of the book: creating project specifications before you start writing code.
What I Liked
I have been a unit testing fanatic for some time, and I really appreciate how much time the author spends talking about automating “tests”… though he is very clear in that “specification by example” is not the same as “test driven development”.
According to the author, automated tests (not necessarily “unit” tests) should describe the system and be human readable – creating living documentation! Overly technical tests (and code) force developers to reverse engineer the business logic – which defeats the purpose, and should therefore be avoided.
In fact, that’s probably the thing I liked most about the book: the idea that “business rules” should be clearly documented and approved before code development begins. Teams should collaborate in order to achieve this goal, and the resulting “specifications” should be revisited often.
In short, mistakes are harder to make when managers, developers and testers all understand the business requirements… and these “requirements” should not be “suggested implementations”.
Some quotes from the book include:
“When teams focused only on test automation, the didn’t get better collaboration”
“Unless the only way to get confidence out of automated specifications for a feature is to run them end-to-end through the UI, don’t do it.”
“Check only UI functionality with UI specifications”.
The author even goes the extra mile, explaining how to get the business leaders on board with the Specification By Example process. There is lots of good advice, and plenty of real-world examples to illustrate each concept.
What I Didn’t Like
There really wasn’t anything to dislike about the book. I will say the book could be a bit dry at times, but as that’s par-for-the-course with other technical books I can’t really complain.
Chapter 2 introduces the concept of “living documentation” – and maybe it’s because I’m too far into the development world, but I found that I didn’t understand precisely what the author was getting at until I saw figure 2.2 (a screenshot) on page 22. Had the author been more clear (or direct) sooner, I would not have been forced to reread the previous pages to re-enforce my new-found understanding.
If you’re a technical manager or senior developer (or in a similar position) you should probably read Specification By Example.
It certainly changed the way I will be approaching future projects, and I will continue to recommend this book for a long time.