Introducing Cucumber

August 10th, 2009

1

Lassie was a liar. For, if you believe the lore, all the dog had to do was create a series of barks that would instantly be translated perfectly into its intended message.

BARK BARK

What’s that girl, Timmy is gonna use thermite to warm up the forest critters?

BARK BARK

Alright, girl. Lead the way!

Such clarity of message, such pristine delivery and such lossless transfer, sadly, does not exist. But perhaps I am being too hard on the courageous male dog whose portrayal of a female brought about much needed acceptance of gender reversal in mainstream American society. Nonetheless, making another understand wholly what you’re thinking is not possible.

Things do get lost in translation.

Here at Border Stylo we deal with this problem on a day-to-day basis. When you are working with a team it is essential to keep the energy and vision of a product transferred to all those involved. To have all members of your team understanding the ‘why’ and the ‘what’ will facilitate the process a thousand fold when it gets down to the ‘how’. And while every slick MBA suit can sell you on the idea of getting everybody on board (they like to call it “buy in”, we call it “I hope you don’t think we’re paying for that obvious advice”), implementing a system is a whole different monster. And in the realm of software development where multiple people have their hands in creating something [editor’s note: in this case, amazing!] it is hard to keep everyone focused. But we have a method we’d like to share and hopefully, it can help you too.

One of our mission statements at Border Stylo is to help humanize technology. To do this we need to humanize the entire process, not just add rounded corners. As such we at Border Stylo adhere to Behavior Driven Design, which in its essence is preoccupied with the way people interact with the product rather than the details of the method (this second being Test Driven Design). Now both of these are very good tools and there’s no such thing as superior. However, we have found an interesting, and one could even be so bold as to say superior value that Behavior Driven Design adds: it allows everyone to understand, from the artisans of marketing to the scientists of architecture. It makes a very opaque process more transparent to all, right brained individuals and left brained individuals alike.

Behavior Driven Design starts at the top of a company. It’s very easy for someone to issue orders like “Build me a better phone!” but that’s not direction. Hell, it wasn’t even very polite. Yet so many times these orders get passed down with little else. Then when final phone is built many a frantic calls are made because the 180 year old boss assumed all phones were rotary and the 20 year old engineer went touchpad. Well, that’s what BDD helps avoid.

Introducing Cucumber

To achieve cohesion across our teams and products we use Cucumber. From the Cucumber wiki: Cucumber is a tool that can execute plain-text documents as automated functional tests.

It’s very colloquial and accessible, kind of like Dr. Phil. But unlike Dr. Phil, Cucumber helps us provide actionable Scenarios (basic walkthroughs of what a user might encounter when dealing with our product, we often correlate Scenarios with the Agile idea of a User Stories), which in return double as a functional test suite for an entire application (a-la Ruby)! That’s what our MBA suits and Dr. Phil would call a “Win-Win.”

Because we create Scenarios grounded in a testing framework interesting things happen. Scenarios become very rich and in-depth, but never complex. They are written for a seven year old to understand, or a very smart 6 year old even (Remedial 8 year olds need not apply).

So let’s get down to step-by-step example!

1.) Define

Let’s use an example from our world here at Border Stylo.

We are building a site that requires the user to log in with their credentials to view their information and interact with the product. That sounds cool, but why are we having our users authenticate at all? What’s the logic there? Is it because all the cool kids have it? We need to know what this feature is for and why we need it.

It is essential to define the why and make the answer known to all. A good definition is essential because as we start hammering out scenarios we might find we are building out things that contradict or are beyond the scope of the Feature definition.

Also, without a solid definition there’s no way you’re going to get a cohesive implementation of the Scenarios when late at night your developer is on a caffeine binge and off debugging on their own while making on-the-fly decisions that will impact your product. With a good definition they will act in the interest and intention of your vision.

The format definitions take are:

Feature: [name] In order to: [business goal, why is this important to the product?] As a [actor/stakeholder, who is this objective for?] I want to [goal, what do I want to accomplish?]

Using this template we start to fill in the blanks and iterate over the definition. After much belly-hoo and the passage of time, here’s what our Feature of Authentication looks like:

Feature: Authentication In order to instill user confidence and assure communications via Glass are available to the intended parties As a user I want to prohibit access to my account unless I have specified otherwise

Now everyone who received these will understand why this is a need of the product, apparently we want people to be confident that their messages are secure. Huh. Go figure. But while this might have seemed logical to you, it is better to have it down in writing to mitigate anyone assuming anything.

To get to the definition we required input and discussions from many sectors of the company. The definitions the UX team might have could be quite different than the Legal team’s. There might be many right answers. We suggest going with the one that resonates most with your development team.

2.) Scenarios

Once the feature has been defined the design team can now begin to add Scenarios to their Features. Because the Scenarios are used for testing it really gives the Design team an incentive to be as thorough as possible. Thinking in this way is of great benefit to the Designers because it pushes them to conceive of more possibilities and make their design as flexible as possible within the constraints of their Personas (we’ll talk about these Personas some other time).

At first your designers will cry about actually having to think through their design. Then they will find it extremely useful to their process and never let it go. But they’ll still cry because crying it cathartic and we designers are all about the soul.

Our Scenarios tell the User Stories in a very clear and concise language. Here is the basic format:

Scenario: [User Story, what the walkthrough will be] Given: [Set up, what are the conditions of the walkthrough] When: [Action, what event will occur to the conditions?] Then: [Expected results, what will happen?]

Using these templates the Design team and the UX team begin to go through and think of the myriad possible Scenarios that can be expected and the results that should happen.

Here’s what one looks like for the scenario:

Scenario: Login Given there is a user with the email "lassie@dawg.com" And I am on the login page When I fill in "login" with "lassie@dawg.com" And I fill in "password" with "barkbark" And I press "login" Then I should be logged in as the user with the email "lassie@dawg.com" And I should be on the dashboard

Done and double done. Now we have a Scenario written in Cucumber, which can be used to execute a actual tests against our app! Now, we need Scenarios for every important User Story (to us and our definition of the Authentication feature).

Which brings us to the costs and the perceived con of using Cucumber and or BDD in general.

Maybe people find that writing Cucumber Features is very time intensive. We can confirm that is true, 100%. Writing Cucumbers is hard work and is an iterative process. But, the benefits are monumental in the long run.

Yes, you do pay up-front, but it is extremely valuable for your development team to have a road map as extensive and as clear as a well written Cucumber Feature. Because before your developers write one line of code the project is defined! And is ready to have test coverage! And it’s awesome!

So don’t listen to those people that say that writing Scenarios or thinking about User Stories is a waste of time. They’re a waste of time. There. I said it. Listen instead to us, your pals at Border Stylo, who both love and respect you.

But only as a friend.

Tagged with: cucumber, user stories

Related Posts

• The Human Aspect of QA Testing

Author