Hopefully not nitpicking, acceptance steps of things that do or do not exist, currently phrased with 'should', e.g.
And "Log out" "link" should exist
should probably be phrased factually, e.g.
And "Log out" "link" does exist
The latter seems to make better sense in a scenario where I am doing things and I can tell for a fact if something exists or not.
Thanks Rajesh.
MDL-43236 is closed and I don't think commenting on it would be useful. I will add instead an improvement issue. It does not have to change the existing 'should/should not' steps. It can just extend the set of steps with 'does/does not' steps which delegate to the 'should/should not' in the background. Then either phrasing could be used without duplicating much.
Hi Itamar,
The "should" is commonly used in Behaviour Driven Development frameworks as in the @Then section we have expectations, which are supposed to be true, but there is no guarantee that is true.
IMO we should not add more step definitions for the same purpose that other steps have, we should try to have a close but strong set of steps so it would be easier to remember; it would be even worst in this case as we would be duplicating a step, which would confuse users.
In many cases acceptance tests are acceptance criteria for delivery. As acceptance criteria they need to be factual rather than potential. The client can set a criterion such as "When I go to A then I see X but I don't see Y". The testing language can match that. Just terminology, I know, but sometimes terminology may be useful.
Language speakers already cope with arguably quite confusing language. So I'm not worried that enriching the testing language with additional phrases for same steps would be a problem. This can be easily done by by aliases. I have not found any documentation on that but it turns out that you can declare more than one @Given in a step definition (without adding or duplicating code) and all these givens will be recognized as valid steps.
Hi Itamar,
As I guess you do it is not a technical problem I would resume my opinion in 2 points here:
David, please do not assume that Moodle test developers will not be able to understand that
Then "element" "selector" should exist
and
Then "element" "selector" exists
are two phrases for the same step.
Gherkin is supposed to look like natural language (a subset of) and as such it already has some ambiguity. Given, When, Then, And, But are interchangeable, but only most of time.
I'm inclined to think that only people who've taken one too many philosophy courses (I for one ) would be bothered by the difference between the potentiality in the first and actuality in the second, or even notice it. Others would probably just use one or the other.
Note that I'm not suggesting to deprecate and replace the "should" terminology. Merely to extend the vocabulary. And most importantly, the extension does not require touching the php. Just adding a few more @Given declarations as aliases.
