Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Same step pattern, different step types are not allowed; additionally step type is ignored in feature files #1425

Closed
uuf6429 opened this issue Apr 8, 2023 · 4 comments · May be fixed by #1428

Comments

@uuf6429
Copy link

uuf6429 commented Apr 8, 2023

Steps defining all step type like so:

    #[Given('/^I take a page screenshot(?: as (.+))?$/')]
    #[Then('/^I take a page screenshot(?: as (.+))?$/')]
    #[When('/^I take a page screenshot(?: as (.+))?$/')]
    public function takeScreenshot(?string $name = null): void
    {

are causing errors like so:

  Scenario: clicking on something  # features/something.feature:3
    Given that I do something
      Step "/^I take a page screenshot(?: as (.+))?$/" is already defined in <...>\Debug\Context::takeScreenshot()
      
      <...>\Debug\Context::takeScreenshot()
      <...>\Debug\Context::takeScreenshot()
    And I am on page 1
      Step "/^I take a page screenshot(?: as (.+))?$/" is already defined in <...>\Debug\Context::takeScreenshot()

The same thing is happening for PHPDoc-based step annotations.

If I remove the #[Given.. and #[Then.., the errors are gone, and behat doesn't complain that I have a step defined as When but is used as Given in the feature file, for example.

Why does this happen? What's the point of using the step type (e.g. @Given) if it is ultimately ignored? (why not just have a @Step annotation/attribute in that case?)

In my opinion, steps should be consider unique by step pattern AND step type. Additionally, misusing steps (defined as Given, but used as Then) should trigger a runtime warning.

@stof
Copy link
Member

stof commented Apr 8, 2023

The step type is purely indicative. It does not impact the matching at all.

And changing that would be a BC break so it cannot be done in Behat 3.x.
Note that the step type is also indicative in Cucumber, so the existing behavior is consistent.

@uuf6429
Copy link
Author

uuf6429 commented Apr 8, 2023

Thanks for the reply!

From what you say, I think the only course of action is to relax the duplicate/ambiguous step check in cases where the annotations/attributes apply to the exact same step (and in which case it wouldn't be a BC break). Wdyt?

Maybe a naive way of doing it is to run array_unique when extracting all Given/Then/When annotations/attributes patterns of a given step method.

If I get some time, I'll see if I can make this happen.

@stof
Copy link
Member

stof commented Apr 18, 2023

Well, there is strictly no benefit of adding it multiple times on the same method

@uuf6429
Copy link
Author

uuf6429 commented Apr 19, 2023

Well, there is strictly no benefit of adding it multiple times on the same method

That is true...in the short term at least.

In my opinion, I still don't like the ambiguity and I would rather have an @Step (if they are all treated equally) or be more strict about Given/When/Then.

The way I see it, there are two ideal cases (as already mentioned) and a middle-ground (which is where we're at), and unfortunately, even that middle-ground is not implemented as expected due to the aforementioned uniqueness problem.

@uuf6429 uuf6429 closed this as completed Apr 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants