Reusable steps: the true benefit of cucumber

[Zach Moazeni]

Hey gals/guys,

I do want to thank all the contributors to cucumber, we have used it on many projects and it continues to "validate" the strategy. There was a recent blog post advocating custom steps rather than existing reusable ones. http://spin.atomicobject.com/2011/06/02/never-say-click-good-cucumber-system-testing-practices/

Today I posted a response arguing that reusable steps is the primary benefit of cucumber http://collectiveidea.com/blog/archives/2011/06/09/reusable-cucumber-steps/ - I wanted to share this to the list because as my company teaches cucumber to developers we keep encountering the idea "But what does this add over (test/unit | rspec | etc) ?" Showing them codebases that defines relatively few custom steps and has high step reuse drives the point home.

That has been our experience both using and teaching the framework so I wanted to put it out there.

--
Zach Moazeni
[i] Collective Idea
http://collectiveidea.com
http://ideafoundry.info

[David Chelimsky]

I wrote a variation of this in a comment on the blog post, but essentially:

Custom steps can be structured to be reusable within a domain, but it requires thought and discipline when they are being created. The imperative steps that ship w/ cucumber-rails require no thought or discipline when they are being created.

But we all know that the longevity of maintenance far exceeds that of the initial writing. From a practical perspective, as requirements change, etc, I find custom declarative steps easier to maintain. Here's why.

* duplication needs to be managed, regardless of what language it is written in
* imperative steps tend to introduce duplication in Gherkin
* declarative steps tend to introduce duplication in Ruby
* for me, Ruby is easier to refactor than Gherkin

Cheers,
David

[Eumir Gaspar]

On Thu, Jun 9, 2011 at 10:00 PM, Zach Moazeni <zach....@gmail.com> wrote:

Hey gals/guys,

I do want to thank all the contributors to cucumber, we have used it on many projects and it continues to "validate" the strategy. There was a recent blog post advocating custom steps rather than existing reusable ones. http://spin.atomicobject.com/2011/06/02/never-say-click-good-cucumber-system-testing-practices/

I've just read his post and would just like to state my opinion here(although im also planning to comment there)

"

• It communicates exactly how the feature works to an end user.
• It makes use of very reusable steps.

Personally, I don’t feel like the first is valuable. My tests are there to validate code, and not to be a user’s manual. "

I have read a lot of posts on how to(or not to) write good cukes, and from what I see, the main "problem" is that people aren't all in the same page. Some prefer to write tests for themselves(developers), for testing(qa testers), for clients(the business people), etc. We can't actually have a "universally" acceptable way of writing cukes if this goes on. I mean, the above statement points out that the cuker is actually writing tests for himself: to validate his code. 

In our small team(and probably some of you too), we write cucumbers both for ourselves and for the client(thereby rendering our client as the QA of his own app). Of course, the cukes SHOULD communicate how the feature works, otherwise, if we just wrote:

When I view the "Time Report" for last month

At some point, either the client or the developer will be confused. According to the cucumber wiki:

"This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders."

Correct me if I'm wrong but cukes were meant to be written first. To describe the app's features. If the feature being described had a step like: "When I view the "Time Report" for last month", people might already have misunderstandings already as developers tend to do whichever they feel should be "right". So in this case, I'd either create a drop down list, or a calendar link for the time report. But what if the client was expecting a link like "View Last Month's Time Report". That would've automatically been a rejected feature.

Anyways, that's just part of my point in that, yes, communicating how the feature works is important. Now, on to opening the can of worms: reusable steps:

Today I posted a response arguing that reusable steps is the primary benefit of cucumber http://collectiveidea.com/blog/archives/2011/06/09/reusable-cucumber-steps/ - I wanted to share this to the list because as my company teaches cucumber to developers we keep encountering the idea "But what does this add over (test/unit | rspec | etc) ?" Showing them codebases that defines relatively few custom steps and has high step reuse drives the point home.

This also touches the imperative, declarative debate in cukes. Ben Mabey already posted about this in his 2008 imperative vs declarative post: there shouldn't even be a debate going around because it depends on the end user, the client. You'll most likely go the route of imperative style and the "brittle" reusable steps if the client wanted exact specifications. What you can do is just merge the two schools of thinking: do the imperative first, then do declarative after. 

I usually make the very first scenario in my features a very imperative style, so the user/client will understand how the feature works. ( I fill in "username" with "Hello", I fill in "password" with "world", etc) Then in the succeeding scenarios, I change that into something like "I fill in the login form". This implies to the reader that the previous two(or more) steps were merged into a single line and that they are one and the same.

 

That has been our experience both using and teaching the framework so I wanted to put it out there.

Just my 2 cents :) 

--
Eumir Gaspar
Ruby on Rails Developer/Rails UI Specialist

github: http://github.com/corroded
tech blog: http://aelogica.com/author/eumir/

odesk: http://www.odesk.com/users/~~8951a3b425021bda

stackoverflow: http://stackoverflow.com/users/334545/corroded

working with rails: http://www.workingwithrails.com/person/19554-eumir-gaspar

linked in: http://ph.linkedin.com/pub/eumir-gaspar/7/969/98a

[Andrew Premdas]

+1 and then some

 

Cheers,
David

--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org