In our latest blog we wrote about “why single microflow testing is not taking off in Mendix teams“. We identified three test adoption blockers that can be traced back to: the size of the investment, the uncertain investment returns and the lack of progress information.
Today we are presenting how a new MTA feature “generate single microflow (unit) tests” is enhancing the test configuration speed reducing the first of the three defined adoption blockers. We will finish this blog with a little sneak-peek about the direction of our innovations that will help to solve the other test adoption blockers as well.
In the past decade, we have seen that development cycles are more and more focused on adding business value in the shortest amount of time possible. Low-code supports that focus by shifting from technical craftsmanship to creating a model that captures business logic and requirements. Based on this model the code is generated, which produces a working app.
As we mentioned earlier, testing and test automation has not made the same shift in focus. Test automation is often relying on scarce expertise, manual processes and a lot of maintenance. We decided to change that perspective and introduced ‘Direct Model Testing‘ last year. This technology utilizes the existing app model to create test scripts instead of leaning on testing expertise to build them from scratch.
Direct model testing saves a lot of time when creating and maintaining test scripts. But we want to enhance the concept with generation. Generating test scripts will further reduce the cost of creating and maintaining tests, leading to a better return on test investments.
Our first innovation in MTA 1.6 was to add a recorder which you can generate tests with, by recording them (see Menditect recorder). This empowers the creation of process tests but is hardly speeding up the creation of single microflow tests (unit tests).
That has changed with MTA version 1.8. In this version we added test generation for single microflows.
Let’s have a look at which actions are needed to configure a single microflow test step. Schematically the process looks like this:
Create object input parameter(s):
Alter object input parameter value(s)
Select microflow for execution
Create assert(s)
Add rollback action
These actions require a lot of clicks and configuration actions, especially when your test scripts are getting large and you have to deal with microflows with a lot of input parameters.
In our 1.8 release (september 2022) we save a considerable amount of time by letting MTA create and fill the input parameters automatically (light blue steps). Configuring a single microflow test is now requiring three manual steps instead of five:
Select microflow for execution
Generate object input parameter(s)
Generate input parameter values
The generator generates for every microflow parameter randomized input values. The following randomization is applied:
Alter input parameter value(s)
Create asserts
With the new process of MTA 1.8 we were able to reduce the number of clicks to set up a single microflow test considerably when MTA generates a single microflow (unit) test. In the video below we show how this works for a unit test that we have frequently used in our demo’s.
If your unit test has more parameters the savings in time can be even larger than shown in this video
We have promised to work on removing key blockers for single microflow testing. Adding the “generate single microflow (unit) tests” option in MTA helps to solve the first of the three blockers; it lowers the test investment to the point that test automation is more profitable. Second, it makes test automation much more intuitive, making it easier for the Mendix developer/tester to create tests.
However, we are not done yet. In the future, we will enhance single microflow test generation by assisting the tester to generate test data that will be retrieved by the microflow under test or one of its sub-microflows (called “generate implicit input parameters”). We even plan to add data variation on test case level and generate data variation based on database content.
In our previous blog we wrote about the need for ‘early testing’. We are going to support that and make MTA capable of testing the application on the developer’s computer. The application can then be tested without the need of deploying the app first (shift left testing).
We do have more innovative ideas around assert generation, test coverage measurement and supporting the test automator with intelligent advice. Our final goal is to make testing so easy that it is a no-brainer to configure tests.
Enter your information and choose a day and time when you would like to receive the demo (1,5 hrs).