Where I work, there are a lot of test cases that need to run to to verify that a field value when modified in one pop-up dialog that is layered on-top of another, is displayed correctly in the other pop-up dialog both before and after saving the record.
For instance, the first pop-up is where the code for a record is added, but there is a another pop-up that allows you to search for another code and replace current one.
So for instance, the scenario could be written as follows:
Given I have a saved record with code 'X'.
When I change the code to 'Y'
Then the modified code is displayed in the dialog
When I save and re-open the record
Then the modified code is still displayed in the dialog
However, from what I've read, multiple When-Then clauses in a scenario should be avoided.
I suppose it could written as follows:
Given I have a saved record with code 'X'.
When I change the code to 'Y'
Then the modified code is displayed in the dialog before the record is saved
And the modified code is displayed in the dialog after the record is saved and re-opened.
Note: Due to the automated testers not being very familiar with the application, the Gherkin test cases need to be spelled out with test data and not be declarative in nature.
The problem with the second option is that the Then clause incorporates and action and is not an assertion per se, so in the step implementation, the Then clause would require the automated testers to code an action to save and re-open the record, which then is kind of like a When statement.
Thanks in advance for any assistance you can provide!
Outside of textbooks this sort of thing comes up all of the time. The gist of why not to have multiple groups of whens and thens is that the resulting scenario doesn't work so well as a specification, only as a test script.
Another downside of having multiple groups of when and thens is that it isn't always so clear why a test is failing. If a test is only testing one thing, then you can usually tell very easily what's gone wrong.
But in my opinion there isn't a one size fits all answer. The factors to consider are:
So firstly, if you aren't using the scenarios as a way to write specifications, e.g. BDD, then the only real downside is that it might not be clear why the test is failing. In my opinion this can usually be addresses by carefully naming your steps, and not trying to squish whens and thens together.
Secondly, if your tests take forever to run, because of the system under test or whatever, then would it really be worth essentially running the test twice with different asserts just to go by the book? A decision that's totally up to you, people have different opinions.
And lastly, the best way to deal with this would be to split the test into two parts, and mock out the beginning steps so that in the second test you can just do the assertion that it worked when you reopen it. However, if you don't have the skill sets available to do this easily if it really a big enough deal to look into? And likewise with how much time you have, is this a big enough deal that it's worth spending the time on? However, one big thing to consider is whether this sort of thing will come up a lot with your test systems in the future. If it will then perhaps it's worth making the time...