[Cucumber:4241] Writing tests that drive web pages questions

[Robert Hanson]

I'm writing scenarios for a web page and have some questions on how to write my tests well.  Comments are appreciated.

 

The web page presents a list of items stored in a database; if you click the "add new" button, you're taken to another page where you fill out a form to add a new item. 

 

Currently, I've written my scenario like this

 

Scenario: I can add and remove an enterprise data field

Given I go to the Enterprise Data Fields page

And I add the item Fred

Then the item Fred exists

 

For the step definitions, I've structured the "I add the item Fred" as follows:

 

Given /I add the item (.*)$/ do |name|

    steps %Q{

    Given I click the button labelled Add New

    And I type #(name) into Field Name

    And I type #(name)2 into Display Name

    And I click the button labelled Save

}

end

 

Questions:

 

1) I'm trying to make the scenario definitions more declarative.  Thus, instead of the individual steps required to add an item, I'm just saying "I add the item XXXX".  The actual functionality for doing so is delegated to the step definition, which contains additional steps.

 

But, the step defintion "I add the item xxxxx" is pretty generic.  There are lots of pages where I "add an item" so as written, this step could appear in lots of scenarios.  So I need to add some context to the step definition to differentiate , so cucumber picks the right one. 

 

I might do something like "I add the Enterprise Data item Fred".  But that seems to be pretty wordy.   Is there a better way of providing context?  How do you differentiate various steps that apply in specific contexts? 

 

 

 

2) I'm specifying a specific item (Fred) in the scenario.  I could (and prefer) having "And I add an item" and let the step definition pick a random value instead of the specific value.  Either is easy to do.  The question is, when someone else (ie product owner) is reading the test, which is better?  

 

Do you get more traction with test readers when you have specific examples.  "Add item Fred", vs "Add an item"?

 

 

3) On the web page, there is a text box.  Left of the text box is the text "Field Name"; the actual textbox has an ID that is unrelated to the text.  I've written the step definition to use the label as it appears on the web page.  That just makes sense to me, as a human reader of the steps.

 

But, somehow I need to map that to the actual ID of the textbox.  One option is to have a map of labels to field IDs; and have a step that performs the lookup ("Field Name" --> field_01_23).  Another option would be to change the step definition to have the field ID instead of the label.  Opinions?

 

 

--
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.

[Matt Wynne]

On 27 Apr 2010, at 18:22, Robert Hanson wrote:

I'm writing scenarios for a web page and have some questions on how to write my tests well.  Comments are appreciated.

 

The web page presents a list of items stored in a database; if you click the "add new" button, you're taken to another page where you fill out a form to add a new item. 

 

Currently, I've written my scenario like this

 

Scenario: I can add and remove an enterprise data field

Given I go to the Enterprise Data Fields page

And I add the item Fred

Then the item Fred exists

 

For the step definitions, I've structured the "I add the item Fred" as follows:

 

Given /I add the item (.*)$/ do |name|

    steps %Q{

    Given I click the button labelled Add New

    And I type #(name) into Field Name

    And I type #(name)2 into Display Name

    And I click the button labelled Save

}

end

 

Questions:

 

1) I'm trying to make the scenario definitions more declarative.  Thus, instead of the individual steps required to add an item, I'm just saying "I add the item XXXX".  The actual functionality for doing so is delegated to the step definition, which contains additional steps.

 

But, the step defintion "I add the item xxxxx" is pretty generic.  There are lots of pages where I "add an item" so as written, this step could appear in lots of scenarios.  So I need to add some context to the step definition to differentiate , so cucumber picks the right one. 

 

I might do something like "I add the Enterprise Data item Fred".  But that seems to be pretty wordy.   Is there a better way of providing context?  How do you differentiate various steps that apply in specific contexts? 

One idea that springs to mind would be to stick with the generic "I add the item xxx" step def, but check what page you're on within the step definition by examining HTML in the page (much as a real user would). Then you're able to call the appropriate set of steps or whatever.

I wonder if there is something we could do to add an extra rule to the way Cucumber resolves step match ambiguities so it were possible to have multiple step definitions for different contexts and have the correct one picked automatically. Can you think of anything we could do here to make this possible?

 2) I'm specifying a specific item (Fred) in the scenario.  I could (and prefer) having "And I add an item" and let the step definition pick a random value instead of the specific value.  Either is easy to do.  The question is, when someone else (ie product owner) is reading the test, which is better?  

 

Do you get more traction with test readers when you have specific examples.  "Add item Fred", vs "Add an item"?

Yes, in my experience specific examples do help but the example data has to be relevant. In your case "Fred" appears to have little to do with the scenario. If you want to validate that the word "Fred" will appear somewhere, in an email message for example, then it becomes relevant. Otherwise it can be distracting.

Try out both styles on test readers and ask them which they prefer.

 3) On the web page, there is a text box.  Left of the text box is the text "Field Name"; the actual textbox has an ID that is unrelated to the text.  I've written the step definition to use the label as it appears on the web page.  That just makes sense to me, as a human reader of the steps.

 

But, somehow I need to map that to the actual ID of the textbox.  One option is to have a map of labels to field IDs; and have a step that performs the lookup ("Field Name" --> field_01_23).  Another option would be to change the step definition to have the field ID instead of the label.  Opinions?

In HTML you can use the "for" attribute on a label tag to link it to a field. webrat and capybara both understand this linkage implicitly, so if you say

fill_in "Field Name", :with => 'value'

That will search for a label containing "Field Name", look at its "for" attribute, then search for the text field with an ID that matches that "for" attribute.

Make sense?

cheers,

Matt

http://mattwynne.net

+447974 430184

[jbandi]

I always wondered why step implementations are global in Cucumber?

If step implementations could be scoped to scenarios then this would
not be a problem. You could provide a different implementation of "I
add the item XXXX" for each scenario (possibly sharing some common
code).

In JBehave you can do this for instance:
http://jbehave.org/reference/stable/configuring-scenarios.html

(ok it might be a bit verbose but with a bit of ruby magic this could
certainly be improved?)

So, why are step implementations global? What is the idea behind that?

[Matt Wynne]

On 30 Apr 2010, at 13:11, jbandi wrote:

> I always wondered why step implementations are global in Cucumber?

We call them 'Step Definitions' in Cucumber. I don't mean to be picky
but it avoids misunderstandings if we use the same words for stuff.

> If step implementations could be scoped to scenarios then this would
> not be a problem. You could provide a different implementation of "I
> add the item XXXX" for each scenario (possibly sharing some common
> code).
>
> In JBehave you can do this for instance:
> http://jbehave.org/reference/stable/configuring-scenarios.html
>
> (ok it might be a bit verbose but with a bit of ruby magic this could
> certainly be improved?)
>
> So, why are step implementations global? What is the idea behind that?

Simply because that's all at least 80% of people using Cucumber have
ever needed.

I would not like to see mandatory mapping of step defs to scenarios
(as JBehave seems to do), but it would be nice if there was a way to
scope them if you wanted to.

I wonder whether tags would be an acceptable way to express the scoping?

Something like

During('@admin') do
Given "I am logged in"
login_as_admin
end
end

WDYT? Should we open a lighthouse ticket and talk further there?

> For more options, visit this group at http://groups.google.com/group/cukes?hl=en
> .
>

[Josh Chisholm]

On Fri, Apr 30, 2010 at 1:36 PM, Matt Wynne <ma...@mattwynne.net> wrote:
>
> On 30 Apr 2010, at 13:11, jbandi wrote:
>
>> I always wondered why step implementations are global in Cucumber?

I like them being global, because it forces me to find new ways to
describe the various "Items" in my system in ways that don't need
qualifying with a context, or as Eric Evans puts it, evolve a
"ubiquitous language". To me, the word "item" is equivalent to
"thing", yet is somehow more acceptable.

I have found that in some cases a step definition may be used to
perform the same action on two completely unrelated "items". But in
those cases the UI tends to be the same, and I would still prefer to
avoid generic terms like "item" so I end up with steps with regex
groups, e.g.

Given ^/I select a (banana|spanner|matchbox)$/

Maybe it's a matter of personal preference.

>
> We call them 'Step Definitions' in Cucumber. I don't mean to be picky but it
> avoids misunderstandings if we use the same words for stuff.
>
>> If step implementations could be scoped to scenarios then this would
>> not be a problem. You could provide a different implementation of "I
>> add the item XXXX" for each scenario (possibly sharing some common
>> code).
>>
>> In JBehave you can do this for instance:
>> http://jbehave.org/reference/stable/configuring-scenarios.html
>>
>> (ok it might be a bit verbose but with a bit of ruby magic this could
>> certainly be improved?)
>>
>> So, why are step implementations global? What is the idea behind that?
>
> Simply because that's all at least 80% of people using Cucumber have ever
> needed.
>
> I would not like to see mandatory mapping of step defs to scenarios (as
> JBehave seems to do), but it would be nice if there was a way to scope them
> if you wanted to.
>
> I wonder whether tags would be an acceptable way to express the scoping?
>
> Something like
>
> During('@admin') do
>  Given "I am logged in"
>    login_as_admin
>  end
> end
>
> WDYT? Should we open a lighthouse ticket and talk further there?

Personally I don't like it. It means we can't look at the words "I am
logged in" and understand how they map to code, without considering
some other context.

Josh

[David Chelimsky]

On Apr 30, 2010, at 7:36 AM, Matt Wynne wrote:

> On 30 Apr 2010, at 13:11, jbandi wrote:
>
>> I always wondered why step implementations are global in Cucumber?
>
> We call them 'Step Definitions' in Cucumber. I don't mean to be picky but it avoids misunderstandings if we use the same words for stuff.
>
>> If step implementations could be scoped to scenarios then this would
>> not be a problem. You could provide a different implementation of "I
>> add the item XXXX" for each scenario (possibly sharing some common
>> code).
>>
>> In JBehave you can do this for instance:
>> http://jbehave.org/reference/stable/configuring-scenarios.html
>>
>> (ok it might be a bit verbose but with a bit of ruby magic this could
>> certainly be improved?)
>>
>> So, why are step implementations global? What is the idea behind that?
>
> Simply because that's all at least 80% of people using Cucumber have ever needed.

I'd say more like 99%. The RSpec Story Runner had scoped step definitions because I *thought* they'd be useful. It turned out that they caused more confusion because you couldn't tell from looking at a feature file which step definitions were being loaded.

> I would not like to see mandatory mapping of step defs to scenarios (as JBehave seems to do), but it would be nice if there was a way to scope them if you wanted to.

Agree.

> I wonder whether tags would be an acceptable way to express the scoping?
>
> Something like
>
> During('@admin') do
> Given "I am logged in"
> login_as_admin
> end
> end

Not sure if During is the right keyword, but something like this could work. And using tags in feature files would make clear when different definitions were being applied. We do that now with the @javascript tag in capybara (for those unfamiliar, putting that tag on a scenario tells capybara to run it in the browser - perhaps @in-browser would be a better tag, but it works :) ). The capybara code sets some variables in Before("@javascript") blocks, like this:

Before('@javascript') do
Capybara.current_driver = Capybara.javascript_driver
end

Then it uses Capybara.current_driver in the steps.

FWIW,
David

[David Chelimsky]

Per my other email, Capybara uses a @javascript tag to know whether to fire up a browser or run a scenario in memory. I find this extraordinarily effective and I get all the context I need from the tag itself.

Considering this "logged in" example, I'm on the fence as to whether I'd use it or not because the binding between the tag and the step is less clear:

@admin
Scenario: assign widgets

Given I am logged in

In this case I might prefer:

Scenario: assign widgets
Given I am logged in as admin

But if we had three scenarios with different roles, it might actually be easier to grok this:

@admin
Scenario: assign widgets

Given I am logged in

@lackie
Scenario: assign widgets

Given I am logged in

@anonymous
Scenario: assign widgets

Given I am logged in

Now if you started getting all clever to create the illusion of DRY and did this:

--
Background:

Given I am logged in

@admin
Scenario: assign widgets

@lackie
Scenario: assign widgets

@anonymous
Scenario: assign widgets
--

Then things are starting to get difficult to understand.

The point is that a feature like this can be very useful if used thoughtfully.

WDYT?

David

[Phillip Koebbe]

On 2010-04-30 7:36 AM, Matt Wynne wrote:
>
> On 30 Apr 2010, at 13:11, jbandi wrote:
>
>> I always wondered why step implementations are global in Cucumber?
>
> We call them 'Step Definitions' in Cucumber. I don't mean to be picky
> but it avoids misunderstandings if we use the same words for stuff.
>
>> If step implementations could be scoped to scenarios then this would
>> not be a problem. You could provide a different implementation of "I
>> add the item XXXX" for each scenario (possibly sharing some common
>> code).
>>
>> In JBehave you can do this for instance:
>> http://jbehave.org/reference/stable/configuring-scenarios.html
>>
>> (ok it might be a bit verbose but with a bit of ruby magic this could
>> certainly be improved?)
>>
>> So, why are step implementations global? What is the idea behind that?
>
> Simply because that's all at least 80% of people using Cucumber have
> ever needed.
>
> I would not like to see mandatory mapping of step defs to scenarios
> (as JBehave seems to do), but it would be nice if there was a way to
> scope them if you wanted to.

This is what motivated me to work on my external runner script. Having
all step definitions loaded automatically seemed a bit too "loose" for
me (being a recovering perfectionist and all), so I wanted to load only
those steps that I specifically "defined" as global and ones that I
created just for the feature that I wanted to run. Ultimately, I ended
up looking for a step definition file that was named according to the
feature file name (these would be the "scoped" steps) and then
everything in a "shared" folder. In many respects, this approach worked
well for me.

But it does have disadvantages, the main one being the inability to run
all features in one cucumber instance. When I want to run the whole
feature set, each feature file gets run independently of all the others,
which means cucumber is executed for each feature. And since I currently
use C[eu]lerity, it's pretty painful.

Even though I have spent considerable amount of time creating a library
that I can work with very easily, I am giving serious consideration to
dumping it because of how long it takes to run the whole thing. And I
don't have the quick feedback loop that is so helpful when trying to go
outside-in. Even without javascript support in a scenario, it takes
10-20 seconds to fire up cucumber, culerity, celerity, run the scenario,
and get feedback. To be honest, I haven't even written a feature in
weeks. I've been trying to spec my views in RSpec and am planning on
coming back at a later date to implement features (when I can give more
time to deciding which toolset I want to use).

If Cucumber had a way of scoping that was transparent, that would have
altered my course considerably.

Peace,
Phillip

[Phillip Koebbe]

I've gone round and round with different ways of doing things like this,
and I've finally settled on structuring my features to be parallel to
the application. For example, if I have an admin namespace for my
controllers that requires an admin to be logged in, I will create my
features in an admin directory and only write admin related scenarios
there. Each feature will have

Background
Given I am logged in as an admin

And whatever steps are necessary to get me to the right page. The same
would be true for a user namespace. Anything that is intended for the
non-logged in general public will have

Background
Given I am not logged in

Keeping the scenarios very focused like this has helped me quite a bit.
It keeps the files smaller and well-defined and I am able to go directly
to particular areas of functionality quite easily. So for the logged in
example, tagging would make the process more difficult for me.

YMMV, though.

Peace,
Phillip

[Matt Wynne]

So could we just do something with a folder structure then?

e.g.
features/
foo.feature
bar.feature
step_defintions/
[global step defs]
admin/
baz.feature
step_definitions/
[admin-specific step defs]

If a step def were found in the folder next to the running feature,
that would be used in preference to any matching global one. So
effectively you could 'override' global step defs by putting one in
the nearby folder.

Is that any better?

cheers,
Matt

http://mattwynne.net
+447974 430184

[Mike Sassak]

>> cukes+un...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/cukes?hl=en.
>>
>

> So could we just do something with a folder structure then?
>
> e.g.
> features/
>  foo.feature
>  bar.feature
>  step_defintions/
>    [global step defs]
>  admin/
>    baz.feature
>    step_definitions/
>      [admin-specific step defs]
>
> If a step def were found in the folder next to the running feature, that
> would be used in preference to any matching global one. So effectively you
> could 'override' global step defs by putting one in the nearby folder.
>
> Is that any better?

I like this. I'd add to it the ability to turn the convention on (or
maybe turn it off). Something like
"Cucumber.namespaced_step_definitions = true" that you could put in
features/support.

Mike

[George Dinwiddie]

jbandi wrote:
> I always wondered why step implementations are global in Cucumber?
>
> If step implementations could be scoped to scenarios then this would
> not be a problem. You could provide a different implementation of "I
> add the item XXXX" for each scenario (possibly sharing some common
> code).
>
> In JBehave you can do this for instance:
> http://jbehave.org/reference/stable/configuring-scenarios.html
>
> (ok it might be a bit verbose but with a bit of ruby magic this could
> certainly be improved?)
>
> So, why are step implementations global? What is the idea behind that?

I think it's important to keep in mind that the powerful aspect of
Cucumber is not that it can run tests, but that it can provide a means
of communicating precisely with non-technical product owners. I've
found that such people don't think in terms of scoping.

With your example above, I might have the step definitions for

I add the item XXXX to the shopping cart
I add the item XXXX to the ToDo list
I add the item XXXX to the trash can
I add the item XXXX to the sum

Alternatively, I might go for

Given I'm working with the shopping cart
When I add the item XXXX
Then ...

I like to keep my scenarios very easy to read and understand without
referring to some hidden context.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Phillip Koebbe]

>> cukes+un...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/cukes?hl=en.
>>
>

> So could we just do something with a folder structure then?
>
> e.g.
> features/
> foo.feature
> bar.feature
> step_defintions/
> [global step defs]
> admin/
> baz.feature
> step_definitions/
> [admin-specific step defs]
>
> If a step def were found in the folder next to the running feature,
> that would be used in preference to any matching global one. So
> effectively you could 'override' global step defs by putting one in
> the nearby folder.
>
> Is that any better?
>

That's the direction I went, but it sounds less complicated than it
really is. For illustrative purposes, please see

http://gist.github.com/385412

That is a partial directory structure of a project I'm working on.
Obviously, there are more feature files than step definition files as I
do try to reuse code. Consider the case of the features in
cuke/features/admin/messages/. There are two features, but only one has
custom steps (defined in cuke/steps/admin/messages/).

Below the directory listing is an example of what my script does for me.
The example command would run all the features for admin/messages, and
you can see that I'm requiring the step files (if they are there) and
everything in steps/shared.

To see it all on one screen makes it look horrible, but it's really very
structured. As I said in a different message, I've taken to making my
features run parallel to my application, even so far as to have an
index.feature, a show.feature, a new.feature, etc, so I can easily map
my features to the functionality. Then, if I need a feature to test
something specific, I throw it in where it seems most appropriate. An
example of this would be county_selection.feature.

Peace,
Phillip

--
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.

[Phillip Koebbe]

On 2010-04-30 11:14 AM, George Dinwiddie wrote:
> jbandi wrote:
>> I always wondered why step implementations are global in Cucumber?
>>
>> If step implementations could be scoped to scenarios then this would
>> not be a problem. You could provide a different implementation of "I
>> add the item XXXX" for each scenario (possibly sharing some common
>> code).
>>
>> In JBehave you can do this for instance:
>> http://jbehave.org/reference/stable/configuring-scenarios.html
>>
>> (ok it might be a bit verbose but with a bit of ruby magic this could
>> certainly be improved?)
>>
>> So, why are step implementations global? What is the idea behind that?
>
> I think it's important to keep in mind that the powerful aspect of
> Cucumber is not that it can run tests, but that it can provide a means
> of communicating precisely with non-technical product owners. I've
> found that such people don't think in terms of scoping.
>

Another powerful aspect of Cucumber is that it's flexible enough to
cater to more technical product owners or even developers themselves. I
know I'm in the minority, but I use cucumber myself as the developer to
work outside-in, and I like to be more precise about interaction with
the application. My client doesn't have time to write features anyway,
and when he sees what I've written, it still makes sense to him because
he is somewhat technical.

It goes both ways.

Peace,
Phillip

[George Dinwiddie]

I notice you said nothing of my suggestions.

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[George Dinwiddie]

I notice you said nothing of my suggestions. Were they too simplistic
for you?

- George

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Phillip Koebbe]

On 2010-04-30 5:15 PM, George Dinwiddie wrote:
> I notice you said nothing of my suggestions. Were they too simplistic
> for you?

You lost me. What are you referring to?

Peace,
Phillip

[George Dinwiddie]

Phillip Koebbe wrote:
> On 2010-04-30 5:15 PM, George Dinwiddie wrote:
>> I notice you said nothing of my suggestions. Were they too simplistic
>> for you?
>
> You lost me. What are you referring to?

The suggestions I made in the email to which you replied.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Phillip Koebbe]

On 2010-04-30 8:03 PM, George Dinwiddie wrote:
> Phillip Koebbe wrote:
>> On 2010-04-30 5:15 PM, George Dinwiddie wrote:
>>> I notice you said nothing of my suggestions. Were they too
>>> simplistic for you?
>>
>> You lost me. What are you referring to?
>
> The suggestions I made in the email to which you replied.
>
> - George
>

I got that much. I just don't understand what your meaning is. I replied
to your message, used the term "another", gave an additional way that
Cucumber is useful, and then wrapped it up with "it goes both ways". My
intent was not to contradict your thoughts but to supplement them. Did
you misinterpret?

Feel free to take this off-list if necessary.

Peace,
Phillip

[Matt Wynne]

So here you're doing something in the Given step definition code to
remember the context so the When step knows what to do?

>
> I like to keep my scenarios very easy to read and understand without
> referring to some hidden context.
>
> - George


>
> --
> ----------------------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------------------
>
> --
> 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
> .
>

cheers,
Matt

http://mattwynne.net
+447974 430184

[Matt Wynne]

I'm sure this would be pretty easy to build. Would anyone find it
useful?

>
>>
>> cheers,
>> Matt
>>
>> http://mattwynne.net
>> +447974 430184
>>
>> --
>> 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.
>>
>>
>
> --
> 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
> .
>

[jbandi]

On Apr 30, 6:14 pm, George Dinwiddie <li...@iDIAcomputing.com> wrote:
> jbandi wrote:
> > I always wondered why step implementations are global in Cucumber?
>
> > If step implementations could be scoped to scenarios then this would
> > not be a problem. You could provide a different implementation of "I
> > add the item XXXX" for each scenario (possibly sharing some common
> > code).
>
> > In JBehave you can do this for instance:
> >http://jbehave.org/reference/stable/configuring-scenarios.html
>
> > (ok it might be a bit verbose but with a bit of ruby magic this could
> > certainly be improved?)
>
> > So, why are step implementations global? What is the idea behind that?
>
> I think it's important to keep in mind that the powerful aspect of
> Cucumber is not that it can run tests, but that it can provide a means
> of communicating precisely with non-technical product owners.  I've
> found that such people don't think in terms of scoping.
>

In my experience there is always a context/scope present when you talk
with non technical stakeholders.
This becomes especially obvious if you have different stakeholders
that talk about the system. There is always an implicit context
present.
So when the accountant says "I add the item" it means something
completely different as when the project-leader says "I add the item".
Those steps are part of different stories/scenarios. So in my opinion
it makes sense to separate also the step definitions.

> With your example above, I might have the step definitions for
>
>   I add the item XXXX to the shopping cart
>   I add the item XXXX to the ToDo list
>   I add the item XXXX to the trash can
>   I add the item XXXX to the sum
>

This is certainly often a good option. But when there is a more
complex context involved, it is not always possible to describe the
whole context in plain-text as part of the step. Also this does not
make the whole scenario more readable, because stakeholders implicitly
talk about their context. Having to repeat the context again and again
in each step is just noise and does not flow naturally.

> Alternatively, I might go for
>
>   Given I'm working with the shopping cart
>   When I add the item XXXX
>   Then ...
>

I think this is not a good option. You have to transport the context
from the Given- to the When-Step and the When-Step then has to react
all the possible contexts. Those contexts are mostly completely
unrelated (adding an item to the shopping-cart vs. adding an item to
the todo-list), part of different stories, part of different
iterations etc... so I would heavily argue to also separate the step
definitions.

[George Dinwiddie]

Matt,

Yes, I often find myself doing that. Since 'given' sets the starting
state, that state is remembered for the 'when' action. Given the
duck-typing of ruby, that state can be widely varying things. I think
it's much the way most people naturally think.

>> I like to keep my scenarios very easy to read and understand without
>> referring to some hidden context.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

--
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.

[George Dinwiddie]

Hi, Jonas,

jbandi wrote:
>
> On Apr 30, 6:14 pm, George Dinwiddie <li...@iDIAcomputing.com> wrote:

[snip]

>
>> Alternatively, I might go for
>>
>> Given I'm working with the shopping cart
>> When I add the item XXXX
>> Then ...
>>
> I think this is not a good option. You have to transport the context
> from the Given- to the When-Step and the When-Step then has to react
> all the possible contexts. Those contexts are mostly completely
> unrelated (adding an item to the shopping-cart vs. adding an item to
> the todo-list), part of different stories, part of different
> iterations etc... so I would heavily argue to also separate the step
> definitions.

Isn't that the purpose of Given to set up the context for When?

Given /^I'm working with the shopping cart$/
@context = ShoppingCart.new

Given /I'm working with the ToDo list$/
@context = User.current.todo_list

When /^I add the item \(.*\)$/ do |item|
@context.add(@catalog.find(item))

The When-Step only knows that the context has a method 'add' which
accepts an 'item'.

I would argue that reusing step definitions is key to creating tests
that are maintainable over a long period of time. If they're all
different, then there's surely a lot of duplication and changes will
ripple through a lot of places. In my experience, this tends to lead to
the tests being abandoned as too much work. The stories and iterations
are not what's important, but the application as a whole. That should
have some consistency across the whole.

Of course, defining a good language for testing a particular application
is not an easy task.

[byrnejb]

On Apr 30, 8:56 am, Josh Chisholm <joshuachish...@gmail.com> wrote:

> On Fri, Apr 30, 2010 at 1:36 PM, Matt Wynne <m...@mattwynne.net> wrote:
>
> > On 30 Apr 2010, at 13:11, jbandi wrote:
>
> >> I always wondered why step implementations are global in Cucumber?
>
> I like them being global, because it forces me to find new ways to
> describe the various "Items" in my system in ways that don't need
> qualifying with a context, or as Eric Evans puts it, evolve a
> "ubiquitous language". To me, the word "item" is equivalent to
> "thing", yet is somehow more acceptable.
>

I find it useful to examine the occasional duplicated step definition
that is revealed by having global steps. I find that these often
uncover orthogonal approaches to similar problems. Not a really big
deal but I find this very informative.