Array
(
)

“Menditect Recorder”

donderdag mei 5, 2022
Markus Travaille, Rolf Bolt
How our passion for ease of use and productivity resulted in Menditect Recorder

Menditect’s team is never satisfied with the status quo. We always look for ways to improve the product we offer to our customers. This is the reason we founded Menditect in the first place. A few years ago we built a very large Mendix app which required test automation.  The maintenance associated with it and the continuous care it needed to work properly frustrated us so much that we wanted something better. Fast forward 3 years and we introduced Menditect to the Mendix community in the summer of 2021. This was our first innovation born out of frustration.

Testers and developers test in different ways

We built the first release of Menditect with the Mendix developer in mind. This made sense since that is also our own background. Mendix developers recognize the usefulness of Menditect’s Direct Model Testing approach immediately when they compare it to other test automation technologies. Test automation, however, is not only the domain of Mendix developers but also of Mendix testers. They have a different mindset and other requirements for test automation tools.

So what is the difference then? Well, it is all about how you test an application. Developers tend to focus on units and components. Small parts of a Mendix app that are relatively easy to test with Menditect since developers know how they were built. Testers, on the other hand, focus more on the whole process the Mendix application needs to support. Testers often test without knowledge about the inner workings of the app.

Testers often use the UI of an application to test the process. It  is possible to relate UI actions to the backend actions that Menditect executes, however, it might be quite some work to do this. For this reason Menditect was not always perceived as a suitable tool for process testing by testers.

From frustration to innovation

We understood their (and our own) frustration that building process test cases is more work with Menditect than you would want it to be. Therefore we identified “support for process testing” as one of the areas where we wanted to improve the productivity of MTA. 

Record and playback is a feature that many testtools provide to create test cases and we wanted something similar. How nice would it be if we could generate process test cases out of UI based actions.

But then the question arose: How do we record from the screen and playback on the backend of Mendix? Menditect needs to translate UI actions to backend actions in order to to execute them. This requires quite more work than just playing back the recorded actions. 

In our previous blog “process testing with MTA” we explained how UI actions relate to backend actions. With the release of Menditect 1.5 we were already able to record the executed microflows based on UI actions of the user. This was helpful and a good first step. But for us, it was not good enough. 

Record an executable test script

In order to make a test case executable you need two more things:

  • Teststeps need to be connected to each other; the output of one teststep should be provided as input for another teststep
  • The UI can change objects or call microflows that require data; in other words, you need to retrieve something first, even if the retrieve is not an explicit action that happens in the UI

This is where the real complexity started. We needed to define logic that connects teststeps to each other. We also needed logic that generates the relevant “retrieve” actions to provide the input for a “change” teststep or a “microflow” teststep. Furthermore this needs to work on all releases of Mendix (7.X, 8,X and 9.X), which have different widgets and behavior in the UI.

From idea to implementation

So now we had a clear definition of the problem. The next step for us was to solve it and create a user-friendly solution.  As often is the case with innovation this is just hard work, lots of rework, testing the prototype and improving it step by step. At Menditect we try to release a new version every 4 weeks, but this time it took a bit longer. The recorder is working and the results are even better than we originally thought. However, we also know that improvement is always possible. Therefore we release this functionality in Menditect 1.6 as Beta.

One of the steps we have done, which took more time than expected, is extensive testing on all kinds of different Mendix apps. Some built by us, some built by others. The more testing we can do, the better the recorder becomes. Therefore we have also added a dedicated “MTA recorder issue” button to make it easier for our users to provide feedback. You are all invited to use the Menditect recorder and provide feedback. If you are not a MTA user, you can still see it in action by subscribing to one of our demo’s.

Next steps

In the next release(s) of Menditect we will continue to improve the ease of use of creating process tests in Menditect. The recorder is a big step forward and will be enhanced over time, but we have plenty of other ideas that we will be working on. We are investigating how we can leverage the MTA value for Mendix apps that use teamserver with Git. We are also making our first steps of testing Mendix workflows. Based on frequent requests from (potential) customers we will work on “on premise” support for Menditect in the next release (1.7) and after that we will start working on support for “local testing” on your development environment.

Conclusion

Menditect is a company that was founded around innovation in combination with a continuous strive to improve the quality of Mendix apps. We continue to invest in making test automation easier and faster for Mendix developers and testers. We do this both by using our own creativity and engaging with our customers.

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

Contact the author

Enter your contact details

Menu