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.

• Validation microflows are excellent starts. They usually need more scope, already separated from the process of saving some data. This limits the unit tests to specific scenarios: a happy path, a failure path and an erroneous data scenario (causing system errors).
• Once you have mastered unit testing, you should move to your core business logic. Especially those calculations that require lots of manual input but have many logic bits in sub-microflows that need lots of steps to test manually. Build unit tests for each of those sub-microflows.
• The last low-hanging fruit item is elements of published and consumed API implementations. Import and export mappings, microflows taking care of published API functions, and handling of data imported during the consumption of API functionality from third parties.

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!