Applies to CucumberStudio 1.0, last modified on January 09, 2020

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 scenarios for CucumberStudio, in which we ensure that a user can change his name in the system. The scenario is the following:

CucumberStudio scenario

Click the image to enlarge it.

Loose coupling

The main idea of loose coupling is to avoid integrating automation related content inside the CucumberStudio scenarios and action words. That means the lowest level of action words will describe actions in the system under test (login, register, create project …) and will need to be implemented by the automation team.

The action words used in Change profile will look as follow:

Create user:

Loose coupling: Create user

Click the image to enlarge it.

Click on profile:

Loose coupling: Click on profile

Click the image to enlarge it.

Update profile name:

Loose coupling: Update profile name

Click the image to enlarge it.

Check profile name:

Loose coupling: Check profile name

Click the image to enlarge it.

Note: 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 developer 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 CucumberStudio, we could write one implementation for the web version and one for the mobile version and use the same test scenarios for both).

Strong coupling

The idea here is to integrate the automation inside CucumberStudio. That means the test and the automation team will both work on the CucumberStudio 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:

Create user:

Strong coupling: Create user

Click the image to enlarge it.

Click on profile:

Strong coupling: Click on profile

Click the image to enlarge it.

Update profile name:

Strong coupling: Update profile name

Click the image to enlarge it.

Check profile name:

Strong coupling: Check profile name

Click the image to enlarge it.

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:

API action words:

API action words

Click the image to enlarge it.

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 should be implemented manually. That said, this work should be done inside CucumberStudio and the automation team should work directly in CucumberStudio 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 CucumberStudio, 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 depends on the team (Will the automation team work inside CucumberStudio?), 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.

Highlight search results