Comments on: Imperative vs Declarative Scenarios in User Stories

By: How we roll at Intent Media « One of the Wolves

How we roll at Intent Media « One of the Wolves — Sat, 09 Jan 2010 03:03:43 +0000

[...] decision of where to put the imlpicit state (no link, unfortunately), as well as whether to write declarative or imperitive step definitions. But it's all up to you. So far we've had success, and I'd recommend following Kurt's blog for more [...]

By: Joseph Wilk » Metrics for Plain Text Acceptance Tests

Joseph Wilk » Metrics for Plain Text Acceptance Tests — Fri, 20 Nov 2009 09:33:14 +0000

[...] Very long scenarios may reflect more abstraction should be used to help make the scenarios easier to read (See declarative vs imperative scenarios: http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/) [...]

By: Ben Mabey

Ben Mabey — Thu, 13 Aug 2009 15:48:50 +0000

Hey Jørgen,
That is a good idea. I’ve actually thought of doing something like that with Cucumber. Basically, you could have a formatter that would take into account any nested steps and output them (indented) under the more declarative parent step. I think this could be helpful for some teams.

By: Jørgen Braseth

Jørgen Braseth — Thu, 13 Aug 2009 10:41:10 +0000

In my opinion, the difference between steps and scenarios is really an artificial one.
What I would have liked to see is a UI that let me read a scenario written “declaratively” and expand on certain parts of the text if i wanted to read it more “imperatively”.
e.g. if i wanted to read the following:
When I add a new animal
On a finer detail-level, i should be able to drill down on this part of the scenario and be able to read:
When I fill in Name with 'Alligator' And select Phylum as 'Chordata' And fill in Animal Class with 'Sauropsida' And fill in Order with 'Crocodilia' And fill in Family with 'Alligatoridae' And fill in Genus with 'Alligator' And check Lay Eggs And click the Create button

By: Mark Dodwell

Mark Dodwell — Thu, 07 May 2009 06:10:44 +0000

I use cucumber for acceptance testing on projects for which I am the client, and I tend to use the “Imperative” style for writing features.

The reason is that although it makes the scenarios more brittle, using the “Declarative” approach just moves the brittleness to the step definitions. So the brittleness overall is really the same, just in a different place. Therefore the declarative approach just adds extra work for no gain.

When I have an external, non-technical party as the client, then this extra work is justified — moving the brittleness down one layer away from the user, from the scenarios into the steps.

By: Leveraging Test Data Builders in Cucumber Steps • Blog Archive • ben.send :blog

Thu, 05 Feb 2009 22:34:38 +0000

[...] the balance between writing declarative scenarios and step reuse in Cucumber can be tricky at times. I have found leveraging a Test Data [...]

By: Testing with the help of machinist, forgery, cucumber, webrat and rspec | IT.Signals

Wed, 07 Jan 2009 08:27:03 +0000

[...] "Imperative" and "Declarative" which is described in detail in the article Imperative vs Declarative Scenarios in User Stories written by Ben Mabey. As an example if I was to rewrite the previous step using the Imperative [...]

By: Ben Mabey

Ben Mabey — Mon, 01 Dec 2008 17:17:22 +0000

Adam, you’re right on. A lot of my stories (cucumber features) now have both styles mixed. I think the “right” mix of the two is different per project and even per problem.

By: Adam

Adam — Mon, 01 Dec 2008 05:23:01 +0000

I know that you mentioned both declarative and imperative are useful in their own contexts, but I just want to add that the best products tend to focus on both types of use-cases. In other words, it is always the little things that make a product great and set it apart from all the other functionally comparable products. Of course, this is usually the client’s prerogative, not the developers. Thanks for the great post!

By: Ben Mabey

Ben Mabey — Thu, 22 May 2008 03:34:32 +0000

Very true. In the end the declarative approach gives you a lot more flexibility because you can swap out your matchers… So you could have a set that uses webrat or a set that uses selenium, or one that uses the objects directly, etc…