I wanted to learn more about Cucumber, what it was exactly, and why it is so popular.
I had (and still have) no plans on using the BDD/Cucumber approach, because I’m very aware of the weaknesses of, e.g., using glue code to implement keywords (or steps, as they are called in Cucumber). More on that in later posts.
I hoped to learn something useful. It turned out that Cucumber seems designed and sold to make it easier for people with no knowledge of computer coding to get into creating automation to drive the system under test (SUT), just like the Ruby language itself that the book emphasizes. But, neither Cucumber nor Ruby are suited to the full quality automation problem space because they drop valuable information on the floor (more on that in a post in this set, and I write a lot on this topic elsewhere).
Why this review? Pulling a review together to inform the reader is the best way for me to learn about it.
Given that the following posts of my review are mostly not positive, I understand that some people might be annoyed. I do not want to annoy people, but I do the review anyway for the same reason as my MetaAutomation project: The software community must get smarter and more effective at quality automation, because software is more important in our lives every year. Readers might learn something, and if the authors of the book write another one, they could use this feedback to make it a better book.
To follow: 7 more posts in this series on “The Cucumber Book, Second Edition”
Future posts (with links, as the posts happen):
- What I like about “The Cucumber Book, Second Edition”
- 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