How to test a Bonita UI Designer page using Cypress

This article uses the Bonita UI Designer to create a simple page, and then shows how to implement Cypress for two test use cases

by Dumitru Corini, Bonitasoft R&D Engineer

Once you’ve made a Bonita UI Designer page, testing it is very important.

To test pages made with the Bonita UI Designer, our team decided to move towards an e2e framework that is fast to set up and allows us to write tests efficiently.

We decided to use Cypress, an open-source, Javascript framework that lets you write Given-When-Then semi-structured tests.


First, this article uses the Bonita UI Designer to create a simple page that lets you register a user.

Then, this article gives two test use cases of Cypress, without diving into the full potential of the tool. If you are interested in uncovering its other possibilities, I suggest checking out their documentation.

You can find everything discussed in this article in the github repository.
The two tests that I will talk about aren’t the only ones that you will find in the repository, so if you want to see more examples, you can clone the repository and then check them out.

Diving into the page structure

The test choices

Cypress tests are made from two distinct parts. The first is about writing the test scenarios in one file and the second is about explaining with code what each line of the scenario will do.
The cypress-cucumber-preprocessor library is used in order to write scenarios in the Given-when-then style.

The two tests that I am going to talk about are :

  • A failure in the creation of the user because the passwords don’t match
  • The loader being displayed while the user is being created

I chose the first because it is a test that we have done and redone multiple times in our pages, but with a little subtlety. In most of the cases, we are checking that a correct API call is made, with the correct parameters and the correct response. In this case, none of that is necessary because the test for password equality is made client-side. Thus the additional thing that is checked is if no API call is made because none is needed.

The second was chosen because it depicts an use-case that seemed pretty interesting to me, and also because the building blocks of the scenario might be useful in a variety of situations, as, for example, the test for checking if the message disappears after three seconds.

Testing user creation failure because the password is not the same

Given The server is started
And API call response for "user creation should not be called" is mocked
When I visit the index page
And All inputs are filled
And I modify the password field
And I try to create the user
Then I see the message about "Passwords don't match."

The idea for this test is to both verify that there is no API call that is made to the user API, and also that there is a message saying that passwords don’t match.

To verify that there is no API call that is made, we can make a route to the user API without actually creating a response, but only by throwing an error.

method: "POST",
url: userAPI,
onRequest: () => {
throw new Error("This should have not been called");

In order to verify that everything works according to plan, we visit the page.


After that, we fill all inputs with information.


Followed by modifying the password to not match the confirm password value.


And the last action on the page being that of creating the user.

cy.contains("button", "Create").click();

After we have setup this specific situation, we want to test that the “Passwords don’t match.” message is present on the page.

cy.contains("p", message).should("be.visible");

After launching the test runner, we can see that the test is executed and is successful.

Testing the loader being displayed while the user is being created

Given The server is started
And API call response for "user created after delay" is mocked
When I visit the index page
And All inputs are filled
And I try to create the user
Then The loader is shown
When I wait for 5000 delay
Then I see the message about "User successfully created."
And The loader is not shown

As you can see, some parts of this test are the same as in the first test. The main things that are different are the definition of the API mock, checking that the loader is shown, waiting for 5 seconds and checking the end-state of the page.

Mocking the API response after 5 seconds lets us have a moment during which the response has not arrived from the user API and thus the loading would be shown.

The response is the same as the one that you would get from the Portal, which lets us be very close to reality.

method: "POST",
url: userAPI,
delay: 5000,
response: "@userCreated"

While the user is created, we verify that the loader is shown.

cy.contains("p", "Creating user.").should("be.visible");

After which we wait for 5 seconds.


And after 5 seconds, when the response arrives, we check that the message disappears.

cy.contains("p", "Creating user.").should("");

As you can see, these tests don’t take a long time to write and can be very powerful.

Awesome! Now you know how to test a UI Designer page with Cypress! You can also check our web-pages project containing pages that we are currently developing.

This article was originally published in

Bonitasoft helps innovative companies worldwide deliver better digital user experiences — for customers and employees — on the Bonita application platform.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store