This is the fifth newsletter in a series about unit testing. See the links at the bottom of this newsletter for the previous iterations. This will be the last of this series. More will likely follow in the future, as there is still much to share about the topic! Now, let’s reflect on the lessons learned over the last decade that I have been implementing unit tests in Mendix applications.

Convincing your team is 60% of the work

Getting started with unit testing is a difficult task. Not only do you need to learn how to efficiently build your code to make it unit-testable. You also need to learn how to create unit test microflows. But by far, my biggest challenge has always been convincing my team that unit testing is an essential part of the development process. It pleases me to learn that there are a lot of Mendix developers out there who are just as interested in the topic as I am. Need some extra help to convince yourself and your team to jump on the unit testing train? Read my newsletters, the Eternal debate and How to get started? for tips to back up your case!

The right tool does the trick

Of course, building your own test microflows directly by calling the microflows you would like to test and pushing a bunch of buttons to run those tests works. But is it way more efficient than testing your app manually? Only barely! The unit testing module that Mendix provides is a great start. But even this lacks several futures to make the developers' lives easier. I have taken care of this by extending the unit testing module (and rewriting parts of it), as I showcased in my newsletter: Improvements to the module! If you want to enjoy the benefits, message me, and I will share the module.

Unit testing is a team effort

In Mendix teams, we often pride ourselves on being multidisciplinary teams with T-shaped team members. However, in most teams, there are still boundaries based on each team member’s specialisation. You have developers, testers, and, of course, a product owner. Those roles must contribute to a successful project and unit testing implementation. Some commercial products even make it possible to work together on this from a user interface instead of in Studio Pro.

A great unit test implementation starts during the user story refinement or investigation of a bug. With proper scenarios set, you can define your unit tests early on in the process and reuse them throughout the initial development and indefinitely after regression testing.

Managers still love numbers

Of course, implementing unit tests costs time, but so does manual testing, or even worse, no testing and deploying bad-quality code. To help your manager understand the cost/benefit ratio, keep track of the unit test coverage, the number of issues found before going live, and the decrease in the problems found after going live. Especially if you start from an existing application, report these numbers frequently to your managers. This way, you can convince them better of your great work by spending that extra time on unit testing the application.

Rapid delivery rate of development disappears without test automation

You can only bring in so many people to do manual testing and keep up with the rapid development. You might attempt UI-based test automation with Selenium or other tools. But in the end, you will hit limitations and have to slow down development or decrease the quality delivered, hoping you didn’t miss a critical bug. By making unit testing part of your development process, you can maintain your speed for longer and keep up with the delivered quality, even though you might be slightly slower at the start of the curve.

So, in conclusion, I would like to say Go Make It and Go Test It!