JBehave
  1. JBehave
  2. JBEHAVE-1070

Loose step matching, not based on StepType

          Details

          • Type: Improvement Improvement
          • Status: Open Open
          • Priority: Major Major
          • Resolution: Unresolved
          • Affects Version/s: None
          • Fix Version/s: None
          • Component/s: Core
          • Labels:
            None
          • Number of attachments :
            0

            Description

            Hi,

            I've recently started working with jbehave, and I am noticing duplication when a step method can be more than one StepType, e.g.:

            @Given("the cart is empty")
@When("the cart is empty")
public void cartIsEmpty() {}

            An easy workaround could be to support the following syntax

            @Given("the cart is empty")
@When
public void cartIsEmpty() {}

            i.e. in case a method has multiple StepType annotations, only one value needs to be not empty.

            But I think there's a more elegant solution.
            The Cucumber Book says something interesting about this:

            Given, When, Then Are the Same.
            It doesn't actually matter which of the three methods you use to register a step definition, because Cucumber ignores the keyword when matching a step. Under the hood, all of the keyword methods are aliases for Cucumber:: RbDsl#register_rb_step_definition. The keywords are really just there for extra documentation to help you express the intent of each step or step definition.
            This means that, whether it was created with the method Given, When, or Then, a step definition will match any Gherkin step as long as the regular expression matches the main text of the step

            I like this concept. At the end of the day, a step is just a method that I may want to call at a certain point (as the m-th or the n-th step) in a scenario.

            Well, different story for given's vs. then's.
            Given my cart is empty != Then my cart is empty
            But, as the cucumber book suggests, then steps should be reworded to use "should"
            => "then my cart should be empty"

            So what about going a little bit farther and defining a generic @Step annotation?

            @Step("the cart is empty")
public void cartIsEmpty() {}

            There is a problem, though, as I think this would break JBEHAVE-196 .
            But then, as far as I understand, the ultimate solution would be to support regexes, wouldn't it? Which is another feature that would be a very-nice-to-have, I think.

            Thanks

              Activity

              Alberto Scotto made changes -
              Field Original Value New Value
              Description Hi,

              I've recently started working with jbehave, and I am noticing duplication when a step method can be more than one StepType, e.g.:

              {code}
              @When("the cart is empty")
              @Then("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              An easy (?) workaround could be to support the following syntax

              {code}
              @When("the cart is empty")
              @Then
              public void cartIsEmpty() {}
              {code}

              i.e. in case a method has multiple StepType annotations, only one [value|http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/annotations/Given.html#value()] needs to be not empty.

              But I think there's a more elegant solution.
              The Cucumber Book says something interesting about this:
              {quote}
              Given, When, Then Are the Same.
              It doesn’t actually matter which of the three methods you use to register a step definition, because Cucumber ignores the keyword when matching a step. Under the hood, all of the keyword methods are aliases for Cucumber:: RbDsl#register_rb_step_definition. The keywords are really just there for extra documentation to help you express the intent of each step or step definition.
              This means that, whether it was created with the method Given, When, or Then, a step definition will match any Gherkin step as long as the regular expression matches the main text of the step
              {quote}

              I like this concept. At the end of the day, the difference between a Given and a Then is just a matter of meaning. And of *position* (i.e. given before then), at most.

              So what about going a little bit farther and defining a generic {code}Step{code} annotation?

              {code}
              @Step("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              There is a problem, though, as I think this would break JBEHAVE-196 (?).
              But then, as far as I understand, the ultimate solution would be to support regexes, wouldn't it? Which is another feature that would be a very-nice-to-have, I think.

              Thanks               		Hi,

              I've recently started working with jbehave, and I am noticing duplication when a step method can be more than one StepType, e.g.:

              {code}
              @When("the cart is empty")
              @Then("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              An easy (?) workaround could be to support the following syntax

              {code}
              @When("the cart is empty")
              @Then
              public void cartIsEmpty() {}
              {code}

              i.e. in case a method has multiple StepType annotations, only one [value|http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/annotations/Given.html#value()] needs to be not empty.

              But I think there's a more elegant solution.
              The Cucumber Book says something interesting about this:
              {quote}
              Given, When, Then Are the Same.
              It doesn’t actually matter which of the three methods you use to register a step definition, because Cucumber ignores the keyword when matching a step. Under the hood, all of the keyword methods are aliases for Cucumber:: RbDsl#register_rb_step_definition. The keywords are really just there for extra documentation to help you express the intent of each step or step definition.
              This means that, whether it was created with the method Given, When, or Then, a step definition will match any Gherkin step as long as the regular expression matches the main text of the step
              {quote}

              I like this concept. At the end of the day, the difference between a Given and a Then is just a matter of meaning. And of *position* (i.e. given before then), at most.

              So what about going a little bit farther and defining a generic @Step annotation?

              {code}
              @Step("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              There is a problem, though, as I think this would break JBEHAVE-196 (?).
              But then, as far as I understand, the ultimate solution would be to support regexes, wouldn't it? Which is another feature that would be a very-nice-to-have, I think.

              Thanks
              Alberto Scotto made changes -
              Summary Loose StepType Loose step matching, not based on StepType
              Alberto Scotto made changes -
              Description Hi,

              I've recently started working with jbehave, and I am noticing duplication when a step method can be more than one StepType, e.g.:

              {code}
              @When("the cart is empty")
              @Then("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              An easy (?) workaround could be to support the following syntax

              {code}
              @When("the cart is empty")
              @Then
              public void cartIsEmpty() {}
              {code}

              i.e. in case a method has multiple StepType annotations, only one [value|http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/annotations/Given.html#value()] needs to be not empty.

              But I think there's a more elegant solution.
              The Cucumber Book says something interesting about this:
              {quote}
              Given, When, Then Are the Same.
              It doesn’t actually matter which of the three methods you use to register a step definition, because Cucumber ignores the keyword when matching a step. Under the hood, all of the keyword methods are aliases for Cucumber:: RbDsl#register_rb_step_definition. The keywords are really just there for extra documentation to help you express the intent of each step or step definition.
              This means that, whether it was created with the method Given, When, or Then, a step definition will match any Gherkin step as long as the regular expression matches the main text of the step
              {quote}

              I like this concept. At the end of the day, the difference between a Given and a Then is just a matter of meaning. And of *position* (i.e. given before then), at most.

              So what about going a little bit farther and defining a generic @Step annotation?

              {code}
              @Step("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              There is a problem, though, as I think this would break JBEHAVE-196 (?).
              But then, as far as I understand, the ultimate solution would be to support regexes, wouldn't it? Which is another feature that would be a very-nice-to-have, I think.

              Thanks               		Hi,

              I've recently started working with jbehave, and I am noticing duplication when a step method can be more than one StepType, e.g.:

              {code}
              @Given("the cart is empty")
              @When("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              An easy (?) workaround could be to support the following syntax

              {code}
              @Given("the cart is empty")
              @When
              public void cartIsEmpty() {}
              {code}

              i.e. in case a method has multiple StepType annotations, only one [value|http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/annotations/Given.html#value()] needs to be not empty.

              But I think there's a more elegant solution.
              The Cucumber Book says something interesting about this:
              {quote}
              Given, When, Then Are the Same.
              It doesn't actually matter which of the three methods you use to register a step definition, because Cucumber ignores the keyword when matching a step. Under the hood, all of the keyword methods are aliases for Cucumber:: RbDsl#register_rb_step_definition. The keywords are really just there for extra documentation to help you express the intent of each step or step definition.
              This means that, whether it was created with the method Given, When, or Then, a step definition will match any Gherkin step as long as the regular expression matches the main text of the step
              {quote}

              I like this concept. At the end of the day, a step is just a method that I may want to call at a certain point (as the m-th or the n-th step) in a scenario.

              Well, different story for given's vs. then's.
              Given my cart is empty != Then my cart is empty
              But, as the cucumber book suggests, then steps should be reworded to use "should"
              => "then my cart *should* be empty"

              So what about going a little bit farther and defining a generic @Step annotation?

              {code}
              @Step("the cart is empty")
              public void cartIsEmpty() {}
              {code}

              There is a problem, though, as I think this would break JBEHAVE-196 (?).
              But then, as far as I understand, the ultimate solution would be to support regexes, wouldn't it? Which is another feature that would be a very-nice-to-have, I think.

              Thanks
              Hide
              Permalink
              Mauro Talevi added a comment -

              While it's true that this constraint is strictly speaking not needed, it is nonetheless useful as it forces scenario writers not to be lazy and think about the syntax and how to word the steps. It is rather unlikely that steps of different types have exactly the same syntax. One could argue that it's a smell.

              That said, there are situations where that may happen. In this case it may be worth introducing an ANY value in the StepType enum (rather than dropping the step type).

              Having an annotation @Step(type=ANY) could be a good suggestion. We could then also have @Step(type=GIVEN) as an alias to @Given, etc ...

              Show
              Mauro Talevi added a comment - While it's true that this constraint is strictly speaking not needed, it is nonetheless useful as it forces scenario writers not to be lazy and think about the syntax and how to word the steps. It is rather unlikely that steps of different types have exactly the same syntax. One could argue that it's a smell. That said, there are situations where that may happen. In this case it may be worth introducing an ANY value in the StepType enum (rather than dropping the step type). Having an annotation @Step(type=ANY) could be a good suggestion. We could then also have @Step(type=GIVEN) as an alias to @Given, etc ...
              Hide
              Permalink
              Alberto Scotto added a comment -

              Having an annotation @Step(type=ANY) could be a good suggestion. We could then also have @Step(type=GIVEN) as an alias to @Given, etc ...

              I'd rather keep it transparent to the user by adopting the syntax I proposed in my original post, if it's not too difficult to implement.

              @Given("the cart is empty")
@When
public void cartIsEmpty() {}

              This means that refactoring the existing code would be just a matter of deleting all of the repeated strings

              ("the cart is empty")
              Show
              Alberto Scotto added a comment - Having an annotation @Step(type=ANY) could be a good suggestion. We could then also have @Step(type=GIVEN) as an alias to @Given, etc ... I'd rather keep it transparent to the user by adopting the syntax I proposed in my original post, if it's not too difficult to implement. @Given( "the cart is empty" ) @When public void cartIsEmpty() {} This means that refactoring the existing code would be just a matter of deleting all of the repeated strings ( "the cart is empty" )

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Alberto Scotto
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated: