Cucumber, what’s the point?

Last tuesday, FedEx dropped off my latest Amazon impulse buy. It is a book called The Cucumber Book: Behaviour-Driven Development for Testers and Developers. This is one of the recent books published by the Pragmatic Programmers. It covers a popular Ruby based testing framework called Cucumber (.) Now cucumber makes a few bold claims on their site. They claim that tests can be written in plain english, and actually test real code. They also claim that with minimal training, even a non-QA person, like a product manager, could write these tests, which would double as specifications.

Now, needless to say, I was rather skeptical. So I spent some time on their site, and saw how their magic works. Let me just say this, while I’m not completely sold on the concept for every situation, they really do have some impressive stuff there. With a minimal effort, I was able to cover a website in basic positive functional testing. I was then able to point a relative newcomer at my project, and have them contribute more testing as a way to familiarize themselves with the project. From the first hour of joining the team, they were able to produce usable and useful tests, while also learning about how this project is supposed to work — and finding new and interesting ways to make it do things it shouldn't.

Is cucumber right for every website I build? Probably not, but so far it is good at making me think about what I’m coding in a bigger picture sort of way. In other words, it makes me think about the code I’ll be writing in a different, more consumer oriented way. This helps to pull me out of my head, and prevents building write-only code that only makes sense as I’m building it, with all the context and thoughts that I have at that moment. Not only this, Cucumber makes it easy to whip out several test scenarios. More test scenarios tend to lead to better task definition, which leads to better code.

So for at least the next while, I am on the cucumber bandwagon, and spitting out tests left and right before putting finger to keyboard on a single line of code. Give it a shot at and see if Behavior Driven Development makes sense for your projects too.

Comments are closed.