Given. When. Then.
With Valentine's day approaching, these might not be the three little words you had in mind. In fact, for the purposes of February 14th... best keep it that way.
But for the rest of the year, what do these words mean?
Gherkin
Again, a gherkin is probably not something for Valentine's day (although, each to his/her own), but many testers will recognise Given/When/Then as the basis for the Gherkin family of languages. But what do they really mean and how come people get so excited about these three little words?
Apparently, Gherkin is ..
"a Business Readable, Domain Specific Language that lets you describe software's behaviour without detailing how that behaviour is implemented".
Really? All that, with just three words? I don't think so.
Let's look at a hypothetical example:
What happened to three little words? Where did all the other ones come from?
They have to come from you. You have to design the rest of the language and you have to make it executable.
You could be forgiven for thinking you're doing all the work. Gherkin is shouting from the rooftops about three little words, and it transpires that everything else is down to you.
You have to design a language.
Designing a language
Designing a language is hard.
"The limits of my language are the limits of my world"
WITTGENSTEIN
So, no pressure then!
Here are 5 tips for designing a specification language.
#1 Start with the nouns
Languages start with nouns. Children gain control over their world by learning to name it.
They begin with nouns and so should you. You can start by writing natural language sentences about your domain, or better still by reading sentences written by your domain experts. Underline the nouns. Some will appear regularly and this is a strong clue that they should appear in your language.
#2 And then verbs
Verbs are either domain specific (e.g. "confirm", "hedge", "closeout" in a trading system) or generic (e.g. "create", "modify", "save").
For the generic verbs, consistency is more important than accuracy. It doesn't much matter whether you say "modify", "alter", "change": just use one consistently.
For domain specific verbs we are looking for phrases that appear natural to the domain experts. Again, read real descriptions about the domain and identify key verbs.
#3 Banish synonyms
There isn't a problem domain in existence where people don't frequently use two words (largely) interchangeably. You need to play the benevolent dictator and decree that, henceforth, only one shall be used. How you decide which is a separate matter, but for now the objective is a single word for a single concept.
It is tempting to "support both", to give people the flexibility to use either one of a range of terms. However, this not only drives up implementation costs and leads to confusion, but you could be potentially harbouring a subtle distinction.
A User says X sometimes and Y on other occasions. You think X and Y are synonyms and treat them as such. The user perceives a subtle distinction and is dutifully choosing his or her words carefully and it is all for nought; the distinction is lost on you.
Banish the use of Y. If someone is told they must always use X, they will most likely tell you if there is a distinction to be made.
If you keep both, it's because you now know they are not synonyms
#4 Avoid pronouns
In the following scenario the use of "it" is unambiguous - it refers to a contract
If we have a subsequent scenario...
... then within the context of the scenario the "it" is also unambiguous.
However, SpecFlow does not naturally limit the scope of the step definitions to be local to the scenario and therefore, taken together, these scenarios have multiple (and therefore ambiguous) definitions of "I save it" and "it is saved successfully".
By adopting a slightly different style (that of avoiding pronouns), this ambiguity can be removed with negligible impact on readability, thus:
#5 Make it personal
Compare the following two partial scenarios
Version 2 is preferred because it makes a stronger statement; it states that it is a trader that performs the validation; not just any old user.
Put version 1 in front of a domain expert and they might assume that you meant "trader" when you wrote "a user" and your subtle misunderstanding (that any user can validate a trade) goes undetected.
There are different ways of conveying that a particular type of user is the subject of the scenario. What matters is that, somehow, your language allows the role of specific users to be conveyed.