The intro post in this series is here.
I am impressed with the attempt to lay out a complete system for the quality automation problem space, and that it addresses many different roles on a software team.
I like the organization of the book. The preview sections and the chapter summaries are helpful and good teaching style.
I like the ongoing example in Part II of the book.
I like that the book does not assume much knowledge of software.
Page 51 has a good activity diagram.
Page 59 has a good point: “… make readability your main goal.” This is a good general goal for naming or comments in code.
On Page 84: “Running Cucumber Test in Parallel” It is a good idea to consider running your checks in parallel. I talk about this in the Parallel Run pattern of MetaAutomation.
On Page 94: “We can’t stress enough how fundamental independent scenarios are to successful automated testing.” This is an important principal of the Atomic Check pattern of MetaAutomation, and always a good idea.
On Page 97: “Testers are too often unfairly regarded as second-class citizens on a software team.” Apparently the authors mean the QA role as well, and it’s very true, but they don’t acknowledge that what they are teaching might have the effect of making this discriminatory attitude even worse with a weak* and lossy** language like Ruby, or a brittle tool like Cucumber, or the whole problem of applying glue-code to steps. More on this in a later post. (TODO link)
On Page 101: “The automated tests are the heartbeat of the team that relies on them, and they need meticulous care and attention to keep them healthy.” This is true, which is why I’ve put so much work into finding and defining a way to do it much better.
Page 137: “… all the same good habits we normally use to write maintainable software apply to the test code we write too.” This is true as well; code quality is as important in automation code as it is in product code, even though the quality ideals for product code are different than for non-shipping automation code.
I also like the index of the book, which looks professionally done.
Future posts (The titles will be linked, as the posts happen):
- What I dislike about the book: Style issues
- What I dislike about the book: How it relates to software development
- What I like about BDD/Cucumber
- What I dislike about BDD/Cucumber: Promises, promises..
- What I dislike about BDD/Cucumber: Architectural issues
- What’s to like or dislike about TDD
*weakly typed, it tends to defer error conditions.
**lossy because it’s a script that defers many kinds of errors to runtime that a compiler would find much sooner.