On 26 February 2012 05:07, mswinson <mswin...@btinternet.com> wrote:
Fundamentally gherkin is about expressing business needs, not about listing
implementation details. What you should do is find a name for x with a
filter of x and x. Then you can just have
When I search for foo
Then I should see results for foo
This is just so much easier to implement, and the feature has less noise.
All the detail about the filters is delegated down to the step definitions,
and ideally down to your actual source. For example if this was a Rails app
you would use foo to define a scope and then have you search use the scope.
Now instead of having the scope defined in two places (the text of your
feature and you source) you are only using the definition in your code.
If you really want to assemble something in gherkin then you can
communicate between steps in a number of ways
1) Use a variable e.g @search
2) Put something in a database and then retrieve it using last in
subsequent steps e.g. Search.last (this relies on the database being
emptied between scenarios)
3) Identify the thing in the feature and then use the id to retrieve e.g.
When I create a foo search, And I add a filter to foo and then
Search.find('foo') in subsequent steps
Variables can be very elegant, especially for feature text but their
overuse can quickly cause chaos (their globals after all)
Using last is fine, until you add something else into the database by
mistake e.g. using a related factory with a side effect
Using an identity is safest but uglifies your features