Array
(
)

Process testing with MTA

donderdag april 7, 2022
Markus Travaille, Rolf Bolt

Explore the differences between process testing through UI and API and Menditects “Direct Model” backend testing

In our previous blog “Direct Model Testing” we explained how Menditect Test Automation (MTA) provides a unique test automation solution that truly differs from existing UI or API based testing tools. Mendix developers and testers understand immediately how MTA provides test automation at the unit and component level. Sometimes it is less obvious how  MTA supports testing at the process level. In this blog we explain how process testing with MTA works and how it differs from UI or API based process testing.

How do Mendix pages and API’s interact with the backend?

In order to understand how UI or API based process testing differs from “Direct Model” backend testing it is necessary to understand how page and API actions interact with the Mendix backend. In the figure below we show  a simplified schema of the types of interactions that exist between the Mendix Page/API and the Mendix backend

There are several types of actions that a page or API can perform.

Page actions

  • Data action (input or display widget)
  • Screen event (on click, on leave, on change, timer based events)
  • Custom widget (front end logic, possibly with backend interactions)
  • Nanoflow (front end logic, possibly with backend interactions)

API actions

  • SOAP/XML message (XML message that is exported or imported by Mendix)
  • JSON/REST message (JSON message that is exported or imported by Mendix)

These page and API actions can trigger a Mendix backend action of the type “Object action” (create, retrieve, change delete) or “Microflow execution”. When or how the backend is triggered is configured in the Mendix page and API models. In the Mendix runtime this results in communication between the frontend/API and the Mendix backend.

Characteristics of (User) Interface vs “Direct Model” process testing

Test automation tools have specific capabilities resulting from the  interaction they have with the system under test. In order to distinguish these characteristics we explore the fundamental limitations of each test automation approach. UI based testing is limited by the functionality that is offered by pages. API based testing by the functionality offered by existing API’s. Menditects Direct Model testing is limited by the backend actions that it can execute directly. In the table below we have made a more detailed description of these limitations per type of test automation tool.

 

This table shows that Menditects Direct model testing only has some limitations related to page specific actions and widgets (nanoflows behave similar to  a front end widget). Although it is obvious that these types of functionalities need testing as well, the risks associated with them are often low and many of these functionalities can be tested with relatively little manual test effort.

Advantages of Menditects “Direct Model Testing”

Because Menditects Direct Model Testing is interacting directly with the Mendix backend it is possible to define tests both at the unit, component and process level. This allows for a very high test coverage in one test automation tool. MTA’s unique consistency checks with the Mendix model make it possible to keep maintenance of your test scripts very low. Since the results of one test case can be used as input for the next test case it is possible to chain tests together to create end-to-end process tests. Furthermore MTA can test multiple Mendix apps in one testrun. This allows for end-to-end testing of processes that run in multiple Mendix apps (microservices testing)

Configuring process testing with Menditect Recorder

With the introduction of the Menditect Recorder (See What Happens below the screen?), it has become possible to record the backend actions as a result of UI and API based actions. From release 1.6 of MTA we add the capability to the Menditect Recorder to generate test cases directly from the recordings. To do this MTA connects all recorded teststeps to each other.

Let us provide an example of how this works with a simple screen action:

  • First a button is clicked that calls a microflow to generate an object.
  • Then the user changes the values of attributes of that object on the screen.
  • In the last step the user saves the object in the screen with a save button that executes a microflow.

The generated test case of this example would result in 3 teststeps in MTA (Microflow – Object Action – Microflow). The Menditect Recorder is aware of the fact that all three teststeps manipulate the same object (same Mendix object ID). Therefore it is possible to connect the three teststeps automatically to each other to form an executable test case.

With the Menditect Recorder it is now possible to create process tests that exactly follow the actions that are executed in Mendix pages. Previously it took time to read and understand the Mendix page model, now it is a matter of minutes to create the teststeps. This makes the creation of process tests faster and easier, while keeping the benefits that Menditect already provides for unit and component testing and the low maintenance due to the consistency checks with changes in the Mendix model.

Conclusion

No test automation tool provides full coverage for all test levels of a Mendix application. With MTA, however, it is possible to define and execute tests at multiple levels. With the addition of the Menditect Recorder we have made the configuration and execution of process tests easier and faster. This allows for non technical testers to create tests with MTA and decreases the setup and maintenance costs of test automation for your Mendix application.

Markus Travaille, Chief Vision officer van Menditect en co-founder van EGALiT

Contact the author

Enter your contact details

Menu