Unit Testing Explained from a Formula One Driver’s Perspective
Did you know that a Formula One car has around 14,500 individual components, and every item is bespoke, with Computer Aided Design. All these separate components, or units, are tested and configured for its own purpose, before putting them in the car, where it serves with its functionality in the application.
Since the Crew members are so confident with all the tested parts, they don’t even flinch when a Formula One car, drives with 60km per hour through the pitlane, and brakes right in front of them at the very last and exact moment and place.
So we know that it’s important to test a (and also your) product. Think of your own car, that you probably won’t drive with your family, knowing it’s a cheaper version and not fully tested car. Fortunately we do not need to worry about whether our car is tested or not, we know and expect it is. We expect food to be checked before it was displayed in the supermarket. We expect a car to stop when we press the brake at the last moment. We expect a bridge to not collapse when we drive over it. We trust it, because it is obvious (so we think) that the product is tested before it was sold. Of course, the same can be said about an application build with Mendix. Our application should not crash and need to be tested.
Still, I often see #Mendix application with (almost) no good fundamental Unit- or Integration-test coverage. The answers I mostly received are “development takes twice as much time” and “I tested it myself after I build it”. Well, believe it or not; Having a Unit Test coverage on your application logic/business layer saves you a lot of time on the long term. Here is why:
1. Reducing Debug Time: Unit Testing are so precisely, that it points out exactly where there is an error or issue in your application
2. Clean code and data: Unit Testing and especially Integration tests are the perfect solution for checking on data frequently. They are perfect ‘data sanitizers’.
3. Easy onboarding: Unit Tests are a very good technique to learn how core functionality in Mendix your application works, because they are all small pieces of simple logic.
4. Stability performance: It is almost impossible to oversee all the Microflows in your Mendix application. So it’s very well possible to change a Microflow, that messes up another (sub) microflow. And that’s when your Unit Tests are your best friends, because they tell you when you do mess up a Microflow.
(Unit) Testing is not an additional task that you do when you have a few minutes left. Testing and especially Unit Testing should be part of your development strategy, because as much as you expect your car to be safe, so does your customer expect you to deliver a safe and stable Mendix application.
