How to limit the scope of step definition to avoid mid-air collisions?

[Arnon]

Hi!

I have a question about step definition and organization. We started
using cucumber recently (with a lot of rspec under our belt already).
The question is how to work with a large(ish) project effectively. We
came across a situation that we don't know how to work with. I'll try
to write question this as a cucumber feature I'd like to have (hoping
that there's already some way to do this):

Feature: scoping step definitions. As a development group who has
thousands of features in hundreds of feature files we want to avoid
mid-air collisions in step definitions due to similar language. For
instance, we have many back-end jobs and they each get executed at
least once as part of the test suite. It is natural for a developer to
write in a feature file "When I execute the job", but it is not
immediately clear that one step definition works for all situations.
Cucumber does not allow duplicate step definitions.

Scenario: Scoping a step definition to a specific tag Given that I
have two feature files for feature-1 and feature-2 And these two files
are being developed by two different developers in the team And both
feature contain a step: 'When I execute the job' But I want to
different implementations for this step, depending on which feature is
used And the two developers are not quite aware of each other's work
And the first developer already committed hid feature file containing
this step for feature-1 And the first developer already scoped his
work somehow (maybe with a tag) And the second developer is put an
identical step is the feature file for feature-2 And the second
developer runs cucumber before having implemented the step definition
And the second developer did not tag his work on feature-2 or tagged
it differently than the first developer Then the second developer
should be notified that there is no step definition for 'When I run
the job' And ideally he should also be notified that such a definition
does exist for tag (or scope) that was used for feature-1

[Lee Hambley]

Arnon,

The obvious answer is small, frequent commits to keep your developers informed, you should maybe think of writing your tests to look more like:

When I run the "Paperclip Sync" Job
When I run the "Database Backup" Job

And keep those implementations as similar as possible, if you need some more logic in side that step definition, you may be able to make that work, YMMV, and I don't recommend making overly complicated test step implementations (don't wanna have to test your tests!)

The alternative is to come up with some standards for writing the test language, simple things like being clear about "a" versus "the" in our project `a thing` looks for "class="thing"" and `the thing` looks for "id="thing"" - such things should allow you to reuse most of your step defs.

- Lee

2009/7/2 Arnon <arnonm...@gmail.com>

[Matt Wynne]

On 2 Jul 2009, at 10:19, Lee Hambley wrote:

> Arnon,
>
> The obvious answer is small, frequent commits to keep your
> developers informed, you should maybe think of writing your tests to
> look more like:
>
> When I run the "Paperclip Sync" Job
> When I run the "Database Backup" Job
>
> And keep those implementations as similar as possible, if you need
> some more logic in side that step definition, you may be able to
> make that work, YMMV, and I don't recommend making overly
> complicated test step implementations (don't wanna have to test your
> tests!)
>
> The alternative is to come up with some standards for writing the
> test language, simple things like being clear about "a" versus "the"
> in our project `a thing` looks for "class="thing"" and `the thing`
> looks for "id="thing"" - such things should allow you to reuse most
> of your step defs.

I guess you could also consider keeping the test suites in separate
folders, so that the "When I run the job" step is defined once per
folder. You can keep the common step definitions in another folder and
require that from the sub-folders.

cheers,
Matt Wynne

http://mattwynne.net
+447974 430184

[Arnon]

Sounds interesting Matt. While Lee's point is well taken, we do have
several subsystems in the project that are not separated out to
different projects (at least yet). Creating several independent test
areas could help with this problem.
Thank you both.

On Jul 2, 5:47 am, Matt Wynne <m...@mattwynne.net> wrote:
> On 2 Jul 2009, at 10:19, Lee Hambley wrote:
>
>
>
> > Arnon,
>
> > The obvious answer is small, frequent commits to keep your  
> > developers informed, you should maybe think of writing your tests to  
> > look more like:
>
> > When I run the "Paperclip Sync" Job
> > When I run the "Database Backup" Job
>
> > And keep those implementations as similar as possible, if you need  
> > some more logic in side that step definition, you may be able to  
> > make that work, YMMV, and I don't recommend making overly  
> > complicated test step implementations (don't wanna have to test your  
> > tests!)
>
> > The alternative is to come up with some standards for writing the  
> > test language, simple things like being clear about "a" versus "the"  
> > in our project `a thing` looks for "class="thing"" and `the thing`  
> > looks for "id="thing"" - such things should allow you to reuse most  
> > of your step defs.
>
> I guess you could also consider keeping the test suites in separate  
> folders, so that the "When I run the job" step is defined once per  
> folder. You can keep the common step definitions in another folder and  
> require that from the sub-folders.
>
>
>
> > - Lee
>

> > 2009/7/2 Arnon <arnonmosc...@gmail.com>

[Andrew Premdas]

2009/7/2 Arnon <arnonm...@gmail.com>

Focusing on your particular jobs example, perhaps this problem indicates that you need to treat jobs differently. So you wnat to have one step definition

  When I execute job (.*) do |job|
    Job::execute_job(job)
  end

And you introduce a job execution module into your cucumber world. Now put any new jobs your working on in here.

---

As for the idea that cucumber should somehow still examine defintions that you have already excluded - this is just a bad idea. It is also something you can do easily enough in your workflow, just run the features with the tag exclusion and get everything working, then run the features without the tag exclusion before you push.

One thing that is very important for any development group is that you have clear rules about when you can push. For example "all features except (@wip) and all specs must pass locally before you can push". Getting the balance just right so that pushes don't break other developers & designers work, yet developers can push frequently is very important. The rules to do this will change as the project develops. Getting a consensus, and even getting developers to recognise this as being important seems to be pretty difficult. But if you do suceed it will address the issues you have raised.


 

[Karl]

We have a similar problem on our project. How exactly would these
different test areas be set up?

It seems to me that cucumber needs a "ruby module" type concept to
allow for custom organization and isolation of tests.

thx.

-karl

> > > I have a question about step definition andorganization. We started

[Zach Dennis]

> Arnon,
> The obvious answer is small, frequent commits to keep your developers
> informed, you should maybe think of writing your tests to look more like:
>
> When I run the "Paperclip Sync" Job
> When I run the "Database Backup" Job

I agree with Lee's approach. I think it would be moving in the wrong
direction if you simply tried to figure out how to have multiple "When
I execute the job" step definitions. It would be a nightmare for
anyone trying to come up with speed unless you had a very very clear
and discoverable convention for knowing which step pertained to which
"When I execute the job" step.

--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)

[Matt Wynne]

On 10 Jul 2009, at 22:04, Karl wrote:

>
> We have a similar problem on our project. How exactly would these
> different test areas be set up?

features
/paperclip
some_paperclip_feature.feature
/support
env.rb
/step_definitions
paperclip_steps.rb
/database
some_database_feature.feature
/support
env.rb
/step_definitions
database_steps.rb
/common
/step_definitions
commont_steps.rb
/support
common_helpers.rb

From the respective env.rb files, you can require common step
definitions & support files so that they're available to both sets of
tests.

You won't ever be able to run both sets of features in a single run,
they'll have to be called separately with

cucumber features/paperclip && cucumber features/database


I'm not saying this is the right way to solve your problem - it's just
a suggestion. I think Cucumber is too new a tool for us to have any
good understanding yet of the practices that are working best for
teams with large numbers of features and steps. As Zach has said,
there are definitely drawbacks with breaking up your features like
this - developers might find it hard to locate a feature quickly, and
it might also get confusing having steps called the same thing that do
different things in different contexts.

Matt Wynne
http://beta.songkick.com
http://blog.mattwynne.net

[Lancer Kind]

On Saturday, July 11, 2009 at 9:42:13 AM UTC-7, Matt Wynne wrote:

features
   /paperclip
     some_paperclip_feature.feature
     /support
       env.rb
     /step_definitions
       paperclip_steps.rb
   /database
     some_database_feature.feature
     /support
       env.rb
     /step_definitions
       database_steps.rb
   /common
     /step_definitions
       commont_steps.rb
     /support
       common_helpers.rb

How does CucumberJVM support this type of file organization?  This would require some kind of Cucumber command line approach.

[Andrew Premdas]

please don't resurrect old threads, particularly ones that are so old. Instead create a new thread with a starting point that does not depend on old posts.

all best

Andrew (moderator)

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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

Andrew Premdas

blog.andrew.premdas.org