Re: Proposal to support achange to Duplicate Steps collision behavior

[Miguel Almeida]

Not sure I understand. Is the goal of this to be able to have 2 steps with the same text but different implementations (e.g: "Given I am sleepy" would have 2 stepDef methods, which would be applied in different features)?

If so, it was discussed a while back. I don't think that's good, as it would add ambiguity to your language. If one of the goals of BDD is to create a common, unambiguous language, then we should strive for that and the meaning of a sentence shouldn't change depending on the context.

Miguel Almeida

On Friday, October 12, 2012 4:53:36 AM UTC+1, carl parziale wrote:

(tried posting previously, hoping this isn't duplicate)

Hello,

Have been working with Cucumber JVM and decided to float this proposal for a behavior change to core Cucumber design.

In Cucumber JVM, have forked the main project to introduce the ability to Annotate Glue StepDef classes to be scoped to Feature files.  That fork is here: https://github.com/carlparziale/cucumber-jvm.    The advantage of this optional annotation is to allow Duplicate StepDef implementations across Glue classes.   If the optional annotation is left off the class, the behavior is as it is today, that is the Step definitions in that Glue class are 'global' and reusable.  

The intended convention would be, scope a Glue Class to a feature file so that as the Feature acceptance tests grow with the system, we avoid collisions in the language.   And if you want to have reusable steps, that can still be accomplished by having classes that don't use the Annotation.   For smaller projects, it may never be used.

was hoping to generate some interest in this design point and instigate debate and possibly acceptance of the idea across Cucumber implementations.

Why do this?   Allows the language in the feature files to be less subject to implementation collisions, allows the flexibility to still create reusable steps. 

Hope this is well received.  Do you have thoughts on this idea positive or negative?

Carl

[Andrew Premdas]

On 12 October 2012 04:53, carl parziale <carlpa...@gmail.com> wrote:

(tried posting previously, hoping this isn't duplicate)

Hello,

Have been working with Cucumber JVM and decided to float this proposal for a behavior change to core Cucumber design.

In Cucumber JVM, have forked the main project to introduce the ability to Annotate Glue StepDef classes to be scoped to Feature files.  That fork is here: https://github.com/carlparziale/cucumber-jvm.    The advantage of this optional annotation is to allow Duplicate StepDef implementations across Glue classes.   If the optional annotation is left off the class, the behavior is as it is today, that is the Step definitions in that Glue class are 'global' and reusable.  

The intended convention would be, scope a Glue Class to a feature file so that as the Feature acceptance tests grow with the system, we avoid collisions in the language.   And if you want to have reusable steps, that can still be accomplished by having classes that don't use the Annotation.   For smaller projects, it may never be used.

was hoping to generate some interest in this design point and instigate debate and possibly acceptance of the idea across Cucumber implementations.

Why do this?   Allows the language in the feature files to be less subject to implementation collisions, allows the flexibility to still create reusable steps. 

Hope this is well received.  Do you have thoughts on this idea positive or negative?

Carl

-1 This idea (which has come up many times before - see Spinach) comes from not understanding the idea of Cucumber's world representing the domain of your application and defining/expressing/reflecting the ubiquitous language of your application. Perhaps greater understanding might remove the desire for this functionality.

All best

Andrew

--
-- Rules --
 
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
 
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 https://groups.google.com/d/forum/cukes?hl=en
 
 

--

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

Andrew Premdas

blog.andrew.premdas.org

[carl parziale]

Miguel,

The primary goal would be to be adaptable to natural language tendencies for product owners anD business folks that don't know the implementation choices. While also preserving the BDD language rigor.

Example
Given I have a product owner writing acceptance tests
When they write a story with duplicate lines
Then Cucumber will warn of the duplicate

Given I have a product owner writing acceptance tests
When they write a story with duplicate lines
And the developer scopes the feature
Then Cucumber will not warn of the duplicate And will execute as if separate scenario

So the Given clause would be reused and same implementation, but the When would be a duplicate, but in reality it's a separate meaning qualified with the And.

Granted, the wording could be rearranged to make this just fine, but I'd rather have my Acceptance writing Product owners use consistent language. The real goal, as I mentioned is to preserve the linguistic consistency.

[Matt Wynne]

Please don't top-post Miguel. See Rule (2) below.

Writing Gherkin files is all about finding a balance between what makes good tests and what makes good documentation. This might involve a bit of a 

negotiation sometimes between a product-facing person who doesn't care much about the testing concern, and a developer who's thinking about how that

phrase will be automated.

Having seen this negotiation happen in training and coaching workshops over and over again, I recognise that it's incredibly valuable: it helps both sides to understand

one another's perspective. Now, I absolutely want to see gherkin files that read like documentation, but I will push back on a product person who wants to use ambiguous

or inconsistent language: ambiguity does not make for good documentation!

I understand the spirit of this idea - facilitating expressiveness for the product owner - but I have yet to see in several years of writing Gherkin a case where I needed it. When I find myself with this problem I take one of two routes:

1) Find some more specific wording. Nearly every time this ends up being more clear

2) Build intelligence into the step definitions to model the state implicit in the scenario

Let me explain (2). Suppose we have this scenario:

Given I am holding a bacon sandwich

When I bite into the sandwich

Then I should say "yummy bacon"

Somewhere else we have this one:

Given I am holding a sausage sandwhich

When I bite into the sandwich

Then I should say "yummy sausage"

There's implicit state in the phrase "the sandwich" - in the first scenario we mean the bacon sandwich and in the second one we mean the sausage sandwich. It's trivial for me to use state inside the step definitions to remember which sandwich has just been mentioned and act on that. I much prefer this approach to the approach you suggest.

Can you give us a concrete example where you think it would be useful? I'd love you to try and break my model!

cheers,

Matt

--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book
Teacher, http://bddkickstart.com

Founder, http://www.relishapp.com/
Twitter, https://twitter.com/mattwynne

[George Dinwiddie]

Carl,

On 10/12/12 8:42 AM, carl parziale wrote:
> Miguel,
>
> The primary goal would be to be adaptable to natural language tendencies for product owners anD business folks that don't know the implementation choices. While also preserving the BDD language rigor.
>
> Example
> Given I have a product owner writing acceptance tests

Do you, in fact, have a product owner writing acceptance tests? Or is
this an anticipated condition?

> When they write a story with duplicate lines
> Then Cucumber will warn of the duplicate
>
> Given I have a product owner writing acceptance tests
> When they write a story with duplicate lines
> And the developer scopes the feature
> Then Cucumber will not warn of the duplicate And will execute as if separate scenario
>
> So the Given clause would be reused and same implementation, but the
> When would be a duplicate, but in reality it's a separate meaning
> qualified with the And.
>
> Granted, the wording could be rearranged to make this just fine, but
> I'd rather have my Acceptance writing Product owners use consistent
> language. The real goal, as I mentioned is to preserve the
> linguistic consistency.

- George

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

[carl parziale]

On Friday, October 12, 2012 4:32:20 PM UTC-4, George Dinwiddie wrote:

Carl,

On 10/12/12 8:42 AM, carl parziale wrote:
> Miguel,
>
> The primary goal would be to be adaptable to natural language tendencies for product owners anD business folks that don't know the implementation choices.  While also preserving the BDD language rigor.
>
> Example
> Given I have a product owner writing acceptance tests

 
> Do you, in fact, have a product owner writing acceptance tests? Or is
> this an anticipated condition?

>> Yes Have Product Owners primarily writing the acceptance tests.  They work with the other team members of course, they don't work in isolation, but we are >> trying to preserve what makes sense to the product owner irrespective of the technical implementation. 

 

 

> When they write a story with duplicate lines
> Then Cucumber will warn of the duplicate
>
> Given I have a product owner writing acceptance tests
> When they write a story with duplicate lines
> And the developer scopes the feature
> Then Cucumber will not warn of the duplicate And will execute as if separate scenario
>
> So the Given clause would be reused and same implementation, but the
> When would be a duplicate, but in reality it's a separate meaning
> qualified with the And.
>
> Granted, the wording could be rearranged to make this just fine, but
> I'd rather have my Acceptance writing Product owners use consistent
> language.  The real goal, as I mentioned is to preserve the
> linguistic consistency.

  - George

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

[carl parziale]

>> Can you give us a concrete example where you think it would be useful? I'd love you to try and break my model!

Example  below.  to set context:

1. Each of these interfaces is significantly different from a technical standpoint, but same Product Owner business goal

Feature Send Payment to Interbank Exchange

  Scenario: Test the payment mechanism 

Given I have an Interbank Exchange Service

When I send it a payment of 10.00

Then it should respond with "payment accepted"

  Scenario: Test the payment mechanism

Given I have an Interbank Exchange Service

When I send it a payment of -10.00

Then it should respond with "invalid payment"

Feature Send a Payment to Chase

  Scenario: Test the payment mechanism

Given I have an Chase Payment Service

When I send it a payment of 10.00

Then it should respond with "Accepted"

Feature Send a Payment to Chase

  Scenario: Test the payment mechanism

Given I have an CitiBank Payment Service

When I send it a payment of 10.00

Then it should not succeed and respond with "Payment too small for this interface"

It seems that in this example the step "When I send it a payment of 10.00"  is going to have very different technical implementations based on the context of each scenario.   Perhaps the wording could be change, but this seems like the correct level precision in the wording to articulate what the Product Owner wants and what is really happening.  

Given that these different technical services have very different interfaces, certificates, different actual API's etc.  I would want them being very separate Glue Class implementations.  

Thoughts?

[Andrew Premdas]

Carl please stop top posting - answers below

When "I send it a payment of 10.00" do

   send_payment @it, 10.00

end

module PayStepHelper

  def send_payment(bank, amount)

    case bank

      when : CitiBank

      when : Interbank

    end

  end

end

World(PayStepHelper)

Now you can do whatever Bank specific things you need to do without having to redefine any step defs

All best

Andrew

 

--
-- Rules --
 
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
 
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 https://groups.google.com/d/forum/cukes?hl=en
 
 

[Chanik]

On Friday, October 12, 2012 12:53:36 PM UTC+9, carl parziale wrote:

(tried posting previously, hoping this isn't duplicate)

Hello,

Have been working with Cucumber JVM and decided to float this proposal for a behavior change to core Cucumber design.

In Cucumber JVM, have forked the main project to introduce the ability to Annotate Glue StepDef classes to be scoped to Feature files.  That fork is here: https://github.com/carlparziale/cucumber-jvm.    The advantage of this optional annotation is to allow Duplicate StepDef implementations across Glue classes.   If the optional annotation is left off the class, the behavior is as it is today, that is the Step definitions in that Glue class are 'global' and reusable.  

The intended convention would be, scope a Glue Class to a feature file so that as the Feature acceptance tests grow with the system, we avoid collisions in the language.   And if you want to have reusable steps, that can still be accomplished by having classes that don't use the Annotation.   For smaller projects, it may never be used.

was hoping to generate some interest in this design point and instigate debate and possibly acceptance of the idea across Cucumber implementations.

Why do this?   Allows the language in the feature files to be less subject to implementation collisions, allows the flexibility to still create reusable steps. 

Hope this is well received.  Do you have thoughts on this idea positive or negative?

Carl

Hello,

I have read all the great opinions and suggestions in this thread.

However, I still want this kind of feature in my mind.

One rule I have about the test automation is,  “Write it fast.  Then forget about it.”

I do test automation to be productive.  But I become very less productive when I make changes in my test code several times.

When I change the test code, I can’t be sure if they all will properly work as before. - Test codes are to eliminate those unexpected problems.  So, do I need test codes for the test codes? Well, you will say no.

Therefore, I usually keep my previous valid test codes as much as possible.

So, what do I want when I found a conflict which concerns test code that I wrote long time - like 30 minutes - ago?

Well, for now, I would write gherkin like “Given It has something[Term: Some Feature #1]” Well, this isn’t too bad.

However, if possible, I’d rather specify the step definition to work only for that Feature or Scenario.  (Then I might leave a sticky note or an issue ticket, so that I can come back and review the duplicate later.)

Yes, I will do refactoring someday by organising and resolving duplicates.  But I wish to do it when I desire, not when it forces me to.  

Do I make point?

73,

Chanik 

[Roberto Lo Giacco]

Why don't you just use straight Java methods and execute them from JUnit? That's going to fulfil your need...

[George Dinwiddie]

Hi, Chanik,

On 1/31/14, 3:51 PM, Chanik wrote:
> On Friday, October 12, 2012 12:53:36 PM UTC+9, carl parziale wrote:
>
> (tried posting previously, hoping this isn't duplicate)
>
> Hello,
>
> Have been working with Cucumber JVM and decided to float this
> proposal for a behavior change to core Cucumber design.
>
> In Cucumber JVM, have forked the main project to introduce the
> ability to Annotate Glue StepDef classes to be scoped to Feature
> files. That fork is here:
> https://github.com/carlparziale/cucumber-jvm

> <https://github.com/carlparziale/cucumber-jvm>. The advantage of

> this optional annotation is to allow Duplicate StepDef
> implementations across Glue classes. If the optional annotation is
> left off the class, the behavior is as it is today, that is the Step
> definitions in that Glue class are 'global' and reusable.
>
> The intended convention would be, scope a Glue Class to a feature
> file so that as the Feature acceptance tests grow with the system,
> we avoid collisions in the language. And if you want to have
> reusable steps, that can still be accomplished by having classes
> that don't use the Annotation. For smaller projects, it may never
> be used.
>
> was hoping to generate some interest in this design point and
> instigate debate and possibly acceptance of the idea across Cucumber
> implementations.
>
> Why do this? Allows the language in the feature files to be less
> subject to implementation collisions, allows the flexibility to
> still create reusable steps.
>
> Hope this is well received. Do you have thoughts on this idea
> positive or negative?
>
> Carl
>
>
>
> Hello,
>
> I have read all the great opinions and suggestions in this thread.
> However, I still want this kind of feature in my mind.
>
> One rule I have about the test automation is, “Write it fast. Then
> forget about it.”

One rule I have about test automation is that it is a form of
programming. My experience is that if I don't maintain my test
automation code as I go along, it quickly becomes hard-to-maintain
spaghetti.

>
> I do test automation to be productive. But I become very less
> productive when I make changes in my test code several times.
> When I change the test code, I can’t be sure if they all will properly
> work as before. - Test codes are to eliminate those unexpected problems.
> So, do I need test codes for the test codes? Well, you will say no.
> Therefore, I usually keep my previous valid test codes as much as possible.
>
> So, what do I want when I found a conflict which concerns test code that
> I wrote long time - like 30 minutes - ago?
> Well, for now, I would write gherkin like “Given It has something[Term:
> Some Feature #1]” Well, this isn’t too bad.
> However, if possible, I’d rather specify the step definition to work
> only for that Feature or Scenario. (Then I might leave a sticky note or
> an issue ticket, so that I can come back and review the duplicate later.)

I realize that this is merely an example, but "it" and "something" are
terribly vague. Judging from other gherkin I've seen, it may be that
your actual gherkin is also quite vague.

I've found that conflicts tend go away when I take the time to choose
the right words. Rather than say "I do" something I say a "registered
user does" something or an "unknown user does" something or an
"administrative user does" something. This not only separates the step
definitions, but also makes the tests communicate better when I read
them a month or three later.

>
> Yes, I will do refactoring someday by organising and resolving
> duplicates. But I wish to do it when I desire, not when it forces me to.

My experience is that when I build up a backlog of issues that need
addressing, it slows me down. Further, my experience is that it's much
harder to organize and resolve issues later, when things are no longer
fresh on my mind and I have a lot to do.

[Yeon Chanik]

Hi George,

> One rule I have about test automation is that it is a form of programming. My experience is that if I don't maintain my test automation code as I go along, it quickly becomes hard-to-maintain spaghetti.

I agree. Codes must be under control as they leave my hands.

> I realize that this is merely an example, but "it" and "something" are terribly vague. Judging from other gherkin I've seen, it may be that your actual gherkin is also quite vague.
>

You’re right again. Maybe I gave you a confusion by giving too simple example, which is not actually used in real life.
It doesn’t happen much. Test codes get improved and organised as my production codes being improved. When finalising and committing my codes, most duplicates are gone. But of course, as you mentioned, it still is vague. Maybe somewhere between 'too vague’ and ’very specific’. ‘Acceptable’?

> I've found that conflicts tend go away when I take the time to choose the right words. Rather than say "I do" something I say a "registered user does" something or an "unknown user does" something or an "administrative user does" something. This not only separates the step definitions, but also makes the tests communicate better when I read them a month or three later.
>
>>
>> Yes, I will do refactoring someday by organising and resolving
>> duplicates. But I wish to do it when I desire, not when it forces me to.
>
> My experience is that when I build up a backlog of issues that need addressing, it slows me down. Further, my experience is that it's much harder to organize and resolve issues later, when things are no longer fresh on my mind and I have a lot to do.

Yes! I totally agree with you.
I do have same opinion and similar experiences.

Let me take some time. I will check if I can explain my thoughts better.
Also, I appreciate your detailed explanation. It is helping me think more clearly and be more specific about this issue. :’)

Regards,

Chanik