Now that you chose the coupling level for your project, it is time to structure it so the test generation will be eased.
Leaf action words
We call leaf the action words that do not call any other action words. Those are the lowest level of action words (when chosing the strong coupling solution, they will represent the automation API, “click”, “fill text” …). One good practice is to tag these action words (for example: “automation:api” or simply “leaf”) so they can be easily recognized (and avoid someone editing them and adding call to other action words inside).
These action words should contain free steps, describing the businness behavior. If you do not provide a description, then the test view in Hiptest will be empty.
High level action word
We call high level any action word that is not a leaf. These action words should only contain calls to other action words (no action or result steps-. The reason behind it is that a free step describe something that will have to be implemented by the automation team. If high level action words only contain call to other action words, hiptest-publisher will automatically generate their content and the automation team will not have to update them.
Strong coupling and low level action words
If you chose the strong coupling solution, it can be interesting to create low level action words. Those action words will simply wrap a call to a leaf action word and give some semantic to it.
For example, let’s imagine you have a
login action word. The basic implementation for it would be:
Now, if we create three low level action words (
fill password and
click on login, each one doing a single call to one of the leaf action words), the implementation would look like this:
Creating those three low-level action words bring three advantages:
loginaction word is now easier to read
- those low level action words can be created by the testers team and left empty. Later on, the automation team will update them to correctly set the value for the calls to the leaf action words
- the optimization result will not be polluted with non-consistent results. The reason behind it is that the results found by the optimizer does not take into account the semantic of the parameters. So for it, it would be perfectly logical to refactor the calls “fill text, fill text, click” into another action word (for example we could find this suite of calls in a
registeraction word) even if there is no semantical logic behind it.
When using this solution, it is also a good practice to tag those action words so they can be easily found by the automation team.
The scenarios should only contain calls to high level action words. This way, it is possible to regenerate the code of the scenarios at each update (considering the action words have not been modified) without needing any human modification.
Mixing automated and manual tests
Structuring a project for automation creates tests that are not really user friendly. For example, a test using the
loginaction word would look like this:
We are studying solution to make it easier to have scenarios made for automation that can be easily reproduced by humans. For now, the best solution is two have two separate test runs: one with scenarios dedicated to manual testing and one dedicated to automated tests.
Once the project is structured as we explained, it should be easy to generate the executable code.