Unify Cukes step styling

[DmitryPrigodich]

Currently, there are all the kind of style used in Cukes project:
* the client imports LDIF:
* resources root is "(.+)"
* status code is (\d+)
* prepare new entity modification
* let variable equal to
* let variable to be random
* let variable be equal to
...and so on

The style of cukes should be unified and set as an example for those who will create their own steps.

First, basically, there are several step styles:

1. action-centered, with an accent on a main verb:
   • check something has happened
   • create something
   • ...
2. subject-centered, with an accent on a main actor:
   • client creates object
   • admin logs in
   • ...
3. object-centered, with an accent on a main object of permutations:
   • button is clicked
   • object is deleted

Action-centered option is useful only for very short scenarios, and as mainly we manipulate with objects without mentioning the actor, the object-centered option is better suited for Cukes needs.

Second, word selection must be unified, so that we can easily find required step without knowing of its existence, just by input of most-used words.
For marking actions there should be some conventions, like:

• "object X is Y" -- means that we set Y value to the object X;
• "object X is deleted" -- means that we delete the object X;
• "object X value should be equal to Y" -- means that we check object X's value to Y;
• "object X should be deleted" -- means that we check that object X is deleted;
  and so on;
  So, 'is' means 'is assigned', 'is %verb%' means 'action is done currently', 'should be %verb%' means 'checking that it is done'. Very easy.
  It's efficient and predictable to have steps of following scheme:
  • create object (+ additional options);
  • read object;
  • update object:
    • create attribute;
    • read attribute;
    • update attribute: add/remove/replace attribute value(s)
    • delete attribute;
  • delete object;
    Plus all the assertion on read object/attribute. Most common are about (not) exists/equal/contains/empty.

Third, as there are several parts of Cukes - REST, LDAP and so on, then for easier finding of required step there should be structure of step itself.
As already told, step should begin with working object clarification, like:

• variable 'X' is 'Z'
  But object could be the value of attribute of system of... So for that, we need to start step from the biggest of that it belongs to. Like here:
• LDAP entity by DN 'A' attribute 'B' value 'C' should be equal to 'D'
  So, object is described from the point it's identified without doubts, if it has some preconditions to be followed.
  We can't define step as 'attribute X value Y is set to Z' as we can't take LDIF-related step to take out JSON attribute and vice versa. So, we need to define step like '%type% object 'X' attribute 'Y' value 'Z''.

Forth, dependent steps are not so good, as it requires unintuitive knowledge of what steps should be used together, one after another.
If the steps tells it modifies the value of an object, then it should do it, not only prepare modifications that could be used by another step.
For multiple data input there is possibility of using Cucumber Data Tables, out of the box.
The same goes for the assertion steps, just it would be better to use SoftAssertions, so that all the list of incorrect values is shown.

Fifth, division to Given/When/Then steps is ineffective and confusing outside the scenario.
We cannot really differentiate what are the Given and When steps, as these are the same, we can only tell it from the scenario, by position:

• if we say start with 'user X is created' then it's Given, if we continue with it, then it's When;
  Then steps are more aligned with assertion steps, but still, scenario can be started with assertion and it would be Given.
  So the most certain way to separate steps is to separate them by type, field of usage, like LdapSteps, RestSteps and so on.

I think, upmentioned improvements would ease life of newcomer testers and increase usability of a project.