Oh my, Cucumber certainly got quite a bit of press recently!
First there was A Case Against Cucumber, but with a title like that I was expecting a more in depth argument.
Although some of the points did seem valid:
- It shows a version of reality
- Step definitions can be hard to grep
- There are testing methods for different cases
When I heard this article was released, I quickly sought it out. I have a yearning to know the pros and cons of Cucumber, as it is not only a part of my job, but I am passionate about its interaction between clients and developers. After reading through the article a few times, I felt compelled to make a case for Cucumber.
Before writing, I took a moment to cool off and compile my thoughts. That’s when I stumbled across An Unusual Case for Cucumber. It turns out that other people found ‘the case against’ compelling enough to counter it. I’m actually going to implore you to read this article because, honestly, it goes over a lot of the points I would have written anyway.
- Cucumber helps you find step definitions
- Describe your features with intent
- Test suites end up in various amounts of brittle in the end.
The article is pretty thorough in its arguments and includes the author’s opinion on how your features should look. (Which I also agree with.)
I feel Cucumber adds an immeasurable amount of value to us as a consultancy. I’m in agreement that a client will most likely never go through and write or read our Cucumber features. After all, we generally build apps that are passed to another set of developers to continue or maintain after our engagement. A couple scenarios happen here, either the client’s developers will begin working alongside us in anticipation of taking over, or we finish up and a team of developers is then hired to maintain it. In both scenarios, our Cucumber features allow the next team to get ramped up, and, in the end, they do a great service to our clients.
Bottom line: Cucumber allows us to inform, in plain English, the intended behavior of applications we build to future developers, rather than forcing them to spelunk through code to figure it out.