Comments on: The Return of the Cucumber http://www.pathf.com/blogs/2009/06/the-return-of-the-cucumber/ Running commentary about agile development, user experience design and Ajax. Fri, 05 Mar 2010 19:33:43 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: Kevin Wilson http://www.pathf.com/blogs/2009/06/the-return-of-the-cucumber/comment-page-1/#comment-7104 Kevin Wilson Thu, 30 Jul 2009 15:44:27 +0000 http://www.pathf.com/blogs/?p=2684#comment-7104 I let the test refer to a key, then have the step definition lookup the value. I let the test refer to a key, then have the step definition lookup the value.

]]> By: Hot chocolate #13 … | Kai Richard König http://www.pathf.com/blogs/2009/06/the-return-of-the-cucumber/comment-page-1/#comment-6676 Hot chocolate #13 … | Kai Richard König Sat, 13 Jun 2009 20:06:16 +0000 http://www.pathf.com/blogs/?p=2684#comment-6676 [...] Agile Ajax » The Return of the Cucumber [...] [...] Agile Ajax » The Return of the Cucumber [...]

]]> By: Ben Mabey http://www.pathf.com/blogs/2009/06/the-return-of-the-cucumber/comment-page-1/#comment-6675 Ben Mabey Sat, 13 Jun 2009 18:00:35 +0000 http://www.pathf.com/blogs/?p=2684#comment-6675 Thanks for another great Cucumber write-up! There isn't a consensus on the writing style issue because it is really dependent on the project and customer IMO. For a more in-depth look at the different type of writing styles take a look at my post: http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/ It is over a year old, so I was talking about RSpec Story Runner, but the issue is the same. What I typically recommend is to start out with the imperative, or specific, style for a new feature. Then, in a different scenario or feature you don't need to redeclare everything so taking the declarative, or general, approach makes more sense. For example, you may want to be specific on what types of fields are present for when creating a new resource. However, if you are testing validation on that form you don't need to outline every field again since it is understood what fields are there. So, it is really a balance on keeping the relevant information present in the steps while hiding the noise within more declarative step definitions. Thanks for another great Cucumber write-up!

There isn’t a consensus on the writing style issue because it is really dependent on the project and customer IMO. For a more in-depth look at the different type of writing styles take a look at my post: http://www.benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories/

It is over a year old, so I was talking about RSpec Story Runner, but the issue is the same. What I typically recommend is to start out with the imperative, or specific, style for a new feature. Then, in a different scenario or feature you don’t need to redeclare everything so taking the declarative, or general, approach makes more sense.

For example, you may want to be specific on what types of fields are present for when creating a new resource. However, if you are testing validation on that form you don’t need to outline every field again since it is understood what fields are there. So, it is really a balance on keeping the relevant information present in the steps while hiding the noise within more declarative step definitions.

]]>