Starting with unit testing has proven to be one of the most difficult challenges for Mendix developers. Many reasons are given, such as needing to know where to start, it costs extra time, and not knowing what should be unit tested. And just as with many other challenges, Mendix explains the basics. They provide a module to get started, a basic explanation documentation, a learning path to learn some basics and a small guide. This is enough to get you interested. Unfortunately, the module has not been updated for years, except for maintenance and the required major Mendix upgrades. This is not as bad as it sounds, as the module stays relevant and contains the basics to get started. You can run a unit test directly from a user interface and get relevant output. But bear in mind, it is extremely basic, requiring much more work or some custom code to make it usable at scale.
If you are serious about unit testing, there are two options. You could take a shortcut and use a commercial solution that offers many options. Or, if you follow this blog series, visit our January meetup, and when you need some in-person help setting this up, reach out to me for coaching or training.
Now let us get on with it and dive right into the specifics of getting started with unit testing!
I will first remove the doubts.
I hear Mendix developers say it costs extra time, and they are partially right. However, unless these same Mendix developers never test their code, they make one common mistake.
They test their applications purely through the user interface and most likely run the same test multiple times. Then, they must explain the functionality to their colleagues during a knowledge transfer. And when they change something related or that very functionality, they must test it again. This is a lot of manual work, which also means human mistakes every time they “execute” the tests. This costs time, but we accept it as part of the process. At least a part of the time spent on manual testing should be diverted into regression unit tests. You build the unit test (preferably at the start) so you may run it repeatedly. It will even give extra context to your functionality.
This approach will save you time, remove the human error that makes every manual execution slightly different, and allow for an easy knowledge transfer. After all, anyone testing it after you have implemented the code will just have to execute the unit tests.
Do you need to know where to start? Then I have already given you the solution. Follow the links from the previous chapters and read the rest of this blog series. At the end of it all, you should know exactly where to start.
What could you unit test? You should start with the basics.
What is next?
There is much more to learn about unit testing, why it is essential and what could be possible with some much-needed changes to the module and the Mendix platform to make unit testing a core part of development on the Mendix platform.
Next up, improvements to the module! Subscribe to the LinkedIn Newsletter and be the first to get notifications when it will be released!
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.