Show Menu

Gherkin++ Cheat Sheet (DRAFT) by

This is a Cheat Sheet for Gherkin++

This is a draft cheat sheet. It is a work in progress and is not finished yet.


Input category - Input categories can be precon­ditions or input variables.
Output category - Expected result data of the test case.
Action category - An action is a simple element of the test process.
Feature call


Single - Select the choice only once.
Default - Is the default value of the choices.

paying method (O): card(D); on site; money transfer
price (O): 0; 100; 1000

WHEN …. THEN price IS 100

The generated test will be:
… paying method­=card, price=100


Constraint name/test name
each constraint may have a name, which is inherited to the generated test
describes precon­dit­ions, and can be omitted
In Multilayer structures the outputs are suppressed
contains the inputs and obligatory
contains the output and obligatory
connects two GIVEN/WHEN/THEN expres­sions
connects a category and a choice of this category, such as MyCat IS MyChoice.
Note 1: The basic difference between GIVEN and WHEN is that if a GIVEN contains a existing test (see Multilayer structure syntax elements), then outputs are suppressed, only input will remain.

Note 2: The original Gherkin syntax requires the GIVEN - WHEN - THEN series.
However, state transition testing requires WHEN - THEN - WHEN - THEN - WHEN - THEN series as well. 4Test permits this syntax.


WHEN original price IS 20 AND reduction is 10 THEN total price IS 19
WHEN original price IS 100 AND reduction is 12 THEN total price IS 88

The same in one constr­aint:
WHEN original price IS 20 | 100 AND
reduction IS 10 | 12
THEN total price IS 19 | 88
Tables reducing the number of constraint if they differ in only the choices. If you are a test analyst, you will understand this constraint and your model will be shorter. On the other hand, the generated test cases will remain unders­tan­dable for everybody.


PRECON­DITION - make models simpler. In lots of the cases when we would like to end-toend test a feature, we have to reach the feature to be tested. This requires to set some precon­dit­ions, i.e. the necessary input values. It’s not reasonable to include these precon­ditions to each constr­aint, and it’s reasonable to separate the precon­ditions and the tests for the feature. PRECON­DITION does this.

AC: Acceptance Criterion

SUB [AC-Name]:
SUB-ke­yword defines an AC as SUB call.
[AC-Name] :
Acceptance Criterion

Use Case Step Counter

First arder Step
Second order Step


CN (I): CHOICE -> SetValue( CN, CHOICE )
button (A): CHOICE -> ClickOn( CHOICE )
Button (A): CHOICE -> ClickOn( CHOICE )
CN (A): clicked -> ClickOn( CN )
CN (O): CHOICE -> Verify­Value( CN, CHOICE )
CN (O): #caption CHOICE -> Verify­Cap­tion( CN, CHOICE )
CN (O): #label CHOICE -> Verify­Label( CN, CHOICE )
CN (O): #place­holder CHOICE -> Verify­Pla­ceh­older( CN, CHOICE )
CN (O): #tooltip CHOICE -> Verify­Too­ltip( CN, CHOICE )
CN (O): #exist yes -> Verify­Exists( CN, 'YES' )
CN (O): @exist no -> Verify­Exists( CN, 'NO' )
CN (O): @exist yes -> Verify­IsA­ctive( CN, 'YES' )
CN (O): @exist no -> Verify­IsA­ctive( CN, 'NO' )
CN (O): @exist yes -> Verify­Has­Focus( CN, 'YES' )
CN (O): @exist no -> Verify­Has­Focus( CN, 'NO' )
CN: Categorie Name

Boolean Verify­Exi­sts();
Boolean Verify­IsA­cti­ve();
Boolean Verify­Has­Foc­us();