Automation with Hiptest publisher – coupling level
One critical aspect during the design of the project will be to choose the coupling level of the project (compared to the automation framework). You mainly have two choices: strong or loose coupling. Both approaches have pros and cons we will detail below. In any case do not worry too much about the choice, it is not a definitive one and it is always possible to go from one solution to the other.
To demonstrate how to write tests with those two approaches, we’ll use one of our own test scenario for Hiptest, in which we ensure that a user can change his name in the system. The scenario is the following:
The main idea of loose coupling is to avoid integrating automation related content inside the Hiptest scenarios and action words. That means the lowest level of action words will describe actions in the system under test (
create project …) and will need to be implemented by the automation team.
The action words used in “Change profile” will look as follow:
Click on user name and
Click on profile buttons are not shown here, but they are simple action words with an action step describing the action to perform.
As you can see, the actions described by the action words are pretty generic and each one will have to be manually implemented by a developper in order to have the automated test running. This asks for more work during the implementation process but it makes it possible to write two implementations of the same action word (for example if there was a mobile app version of Hiptest, we could write one implementation for the web version and one for the mobile version and use the same test scenarios for both).
The idea here is to integrate the automation inside Hiptest. That means the test and the automation team will both work on the Hiptest project. With this type of project, the lowest level of action word will describe the automated tasks (click, fill text, open url …) and will be called by higher level action words.
With our previous example, the action words will look like this:
As you can see, each action word calls lower action words that we called “API action word”. Each one was tagged with “automation:api” so they can be easily filtered as seen in this screenshot:
Each of these action word contain a single step describing the action it performs.
The main advantage of this solution is that implementation is reduced to its maximum, as only the API action words will have to be manually implemented. That said, this work will have to be done inside Hiptest and the automation team will have to work directly in Hiptest to create the content of the higher level of action words.
Another drawback of this solution is when the test scenario needs many fixtures. For example in Hiptest, we have a test checking that the folders structure created in scenarios is replicated when creating a test run. So we have an action word called “Load project with folder structure”. This action word is not implemented by using calls to API action word as it would be way too long to create each item in the test and then create the test run (and this part is not the subject of the test, it belongs to other tests ensuring the process of creating folders and scenarios is working as expected). So this fixture action word is considered as an API action word and is implemented manually, even if it does not really belong with the same class of action words as “click” or “open url”.
As you can see, there is no good or bad choice of coupling level. It mainly depend on the team (will the automation team work inside Hiptest), the type of project (will multiple systems be tested by the same scenarios). Once the choice of automation level is defined, it is time to structure the project to ease automation.