Is there a technical difference between given, when and then?

[dtgriscom-ta]

I (mostly?) understand the usage guidelines behind given, when and then. But, to fully understand using behave, I need to know what these keywords actually do, and what the differences are between them. And, AFAICT, there's no actual difference.

My understanding is that when a Scenario: in a feature file is parsed, each given, when or then keyword is handled in order. The keyword:

1. captures the line of text after it
2. looks for a function in the steps/ folder that is decorated with @<keyword>('<line of text>')
3. executes the function
4. if the function fails, the scenario fails
5. The next keyword is processed.

Is that what's going on in the background? In other words, the scenario

  Scenario: run a simple test
     Given we have behave installed
      When we implement a test
      Then behave will test it for us!

would, once I renamed the step decorators, behave identically to the scenario

  Scenario: run a simple test
     Then we have behave installed
      Given we implement a test
      When behave will test it for us!

?

(Call me overly detail-oriented, but I could never figure out AppleScript. Behind the apparently-natural-language code were all these unstated rules, and I was forever getting stymied by the rules.)

[blaisep]

@dtgriscom-ta , If I understand your question....

Given
When
Then

are keywords which the step registry uses to associate the statement with functions in the steps folder that have been decorated with the corresponding keyword .
These keywords are established by convention and you can change them to suit other national languages (Norwegian and French are popular alternatives).

[dtgriscom-ta]

That's what I'm thinking. In other words, there's no functional difference between the three. (Not that I was planning on reversing their order in my scenarios, but I do like to know what's going on behind the scenes.)

[jenisys]

Given, when, then are basically only categories to lookup step in behave. In addition, the @step decorator can be used for any of the other three cases. But in reality this seldom used or sensible. The reason for this is that the step implemention function body is different for each case/category:

• Given steps are used to setup something or check that a precondition is met
• When steps wait that a condition is met, an event occurs or trigger an event
• Then steps checks if the expected outcome is reached by using assertion statements

NOTE:
If you look at your renamed keyword example, it leads to complete confusion for other people that are tying to understand what you are doing. You basically have broken the communication contract.

[dtgriscom-ta]

I know there needs to be mental clarity, and it's important to follow the conventions with any programming language. There's no good reason to use the keywords backwards, and I wouldn't (at least, in production).

But, I personally work best when I understand what the reality is behind the convention. And, I'll suggest that others may feel the same, and would benefit from documentation that explains how each is implemented differently, or that they all are implemented the same.

[blaisep]

Hi Dan, Yes I am in violent agreement. That said, I think this topic is broadly applicable to gherkin, not just Behave. I can help you with a PR to the behave docs, and I can get you in touch with gherkin upstream. IMHO it's unfair to ask Jens to document something that's not specific to his project

…

On Sun, Apr 17, 2022, 5:25 PM Dan Griscom ***@***.***> wrote: I know there needs to be mental clarity, and it's important to follow the conventions with any programming language. There's no good reason to use the keywords backwards, and I wouldn't (at least, in production). But, I personally work best when I understand what the reality is behind the convention. And, I'll suggest that others may feel the same, and would benefit from documentation that explains how each is implemented differently, or that they all are implemented the same. — Reply to this email directly, view it on GitHub <#1016 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB6D6BYSO4L325224OMQADVFR6UZANCNFSM5TT2GKBQ> . You are receiving this because you commented.Message ID: ***@***.***>

[dtgriscom-ta]

Good idea; I'll work on a PR.

[dtgriscom-ta]

#1017