This email is the sixth in a series on unit testing. For the prior incarnations, see the links at the bottom of this message. This will be the series’ final installment. There’s still a lot to discuss about this subject, so more will probably come later! Let’s now consider the things I’ve learnt in the ten years that I’ve been using unit tests in Mendix applications.
Getting your team on board is 60% of the job.
It can be challenging to begin unit testing. To make your code unit-testable, you also need to learn how to construct it efficiently. The creation of unit test microflows is another skill you must acquire. But persuading my team that unit testing is a crucial step in the development process has always been the largest obstacle I’ve faced. Finding out that there are many Mendix developers who share my interest in the subject makes me happy. Do you need more assistance persuading your team and yourself to embrace unit testing? To support your position, read my newsletters, the Eternal discussion, and How to get started!
The appropriate tool completes the task.
Naturally, creating your own test microflows directly by invoking the microflows you want to examine and pressing a few buttons to initiate those tests is effective. Is it, however, any more effective than personally testing your app? Just barely! Mendix’s unit testing module is a fantastic place to start. However, there are still a number of opportunities to improve the lives of developers. As I demonstrated in my newsletter, “Improvements to the Module,” I have addressed issue by expanding and rewriting portions of the unit testing module. Send me a note, and I’ll send you the module so you can take advantage of the benefits.
Teamwork is required for unit testing.
Mendix teams frequently take great satisfaction in having T-shaped team members and being multifunctional teams. Nonetheless, most teams still have limitations based on the areas of expertise of each team member. There are testers, developers, and a product owner, of course. A project’s and unit testing’s successful execution depends on those roles. In fact, several commercial applications allow collaboration on this from a graphical user interface (GUI) rather than Studio Pro.
When an issue is being investigated or a user story is being refined, a wonderful unit test implementation begins. When you build up your scenarios correctly, you can create unit tests early in the process, use them for all of the initial development, and keep using them long after regression testing is complete.
Numbers are still a favorite among managers.
Unit testing takes time to implement, of course, but so does manual testing, or worse, writing code without testing and releasing subpar code. Keep track of the unit test coverage, the number of issues discovered before to going live, and the decline in issues discovered subsequent to going live in order to assist your management in understanding the cost/benefit ratio. Report these data to your supervisors on a regular basis, especially if you are starting from an existing application. By taking the extra effort to unit test the program, you can persuade them even more of your excellent work.
Without test automation, the development process’s rapid delivery rate vanishes.
There’s only so many people you can hire to perform manual testing while maintaining the pace of rapid development. You might try using Selenium or other technologies for UI-based test automation. However, eventually you will run into constraints and have to reduce the quality provided or slow down development in the hopes that you didn’t overlook a crucial flaw. Even if you may start off a little slower than others, you may stay on pace and meet delivery quality if unit testing is integrated into your development process.
I’d like to conclude by saying, “Go Make It and Go Test It!”
