I like applying a “ubiquitous language” that is standard across roles for a given project. That should improve communication, especially across roles. On pages 135-136 the authors make some good points on ubiquitous language as it applies to the worked example of Part II.
I like that Cucumber applies the BDD concept of communication to make the checks slightly more self-documenting than the more traditional named method for the whole check. (By “slightly” I mean it goes maybe 10% of the distance needed in the correct direction. More on this elsewhere.)
On page 50, “… Cucumber assumes that a step has passed unless its step definition raises an exception.” I think this is a more effective approach than using a check framework that “expects” certain exception types for negative tests.
I like that the check verification itself is considered a separate step.
I also like that the Cucumber tool is designed with the intent of making automation very approachable to people who are new to the practice.
Previous posts in this series:
- Introductory post
- What I like about “The Cucumber Book, Second Edition”
- What I dislike about “The Cucumber Book, Second Edition”: Style issues
- What I dislike about the book: How it relates to software development
Future posts (with links, as the posts happen):
- What I dislike about BDD/Cucumber: Promises, promises..
- What I dislike about BDD/Cucumber: Architectural issues
- What’s to like or dislike about TDD