Skip to main content

Why is Testability Important?

For Mendix applications, achieving high testability is intrinsically linked to maintainability, which in turn is tightly coupled with high structural quality. If structural quality is low, the application often becomes brittle, leading to an over-reliance on costly and inflexible end-to-end (E2E) GUI testing.

1. The Problem: Unmaintainable Software ("Software Dragons")​

Low-code development environments like Mendix promote high development speed, with Mendix claiming software development is six times faster than traditional methods. This speed perfectly complements the DevOps idea of rapidly converting business concepts into working services.

However, without disciplined architectural practices, the inherent complexity of business solutions, combined with rapid development cycles, can cause applications to quickly become difficult to maintain and adapt. This problem, described as the application turning into an unmanageable "software dragon," often emerges over time and forces organizations to spend a significant portion of their IT budget on application maintenance and technical debt and instead of the implementation of new business requirements.

The dragon in the basement

It all starts innocently enough. One sunny afternoon, you stroll into a pet store and fall in love with a tiny, blinking lizard. You bring it home, set it up in a cozy terrarium, and feed it little meal-worms while your kids marvel at your exotic new buddy. Life is good.

But then... it grows.

Soon, the lizard wants crickets. Then bigger crickets. Then mice. You upgrade the terrarium once, twice, and then realize - this is no lizard. This is a dragon in disguise.

You relocate it to a reinforced cage in your basement. You start buying rats. Then rabbits. You’re now on a first-name basis with the guy at the livestock supply store.

And still, it grows.

The day you start sheep-feeding, it nags you that you don’t even know if it’s a prisoned pet - or if you’re the prisoner. You’d love to get rid of it. But deep down, you know: if you stop feeding the beast, it might not stay in the basement. It might come looking for you.

2. Causes of Low Structural Quality​

Several factors contribute to the rapid decay of software quality and subsequently hinder testability:

  1. Lack of Architectural Focus: Development teams, particularly in short Agile iterations, often prioritize delivering business functionality quickly and neglect the necessary attention to proper design, architecture, and code standards. This neglect leads to code duplication, sprawl, and rapid decay of structural quality.
  2. Developer Experience: The accessibility of Mendix means that developers who lack traditional software development or architectural knowledge ("citizen developers") are involved in building applications. While the Mendix toolbox hides code complexity, complex business requirements still demand professionals with a capacity for conceptual thinking, and a lack of skill can introduce poorly designed solutions and technical debt.
  3. Flow-driven Thinking: Low-code tools often make developers work in small, sequential steps, building microflows until they reach the final result, instead of designing clear data structures and functional boundaries. This step-by-step approach makes the system grow as a series of small decisions rather than a well-organized design. As a result, it becomes harder to see the overall purpose, and testability is reduced.

3. Benefits of Designing for Testability​

Adopting a structured, testable architecture yields substantial benefits, particularly in the long run:

  • Cost and Productivity Savings: Working under a standardized architecture, even though initially demanding effort, saves time by facilitating code reuse, modification, and extension.
  • Improved Code Stability and Reliability: Separating interaction and navigation from the business logic helps reduce regression problems. This structure, together with clear data integrity checks, prevents side effects from code changes and keeps errors to a minimum. As a result, the risk of costly fixes or release rollbacks caused by data issues is lower, and the business experiences fewer interruptions.
  • Faster Time-to-Market: Structured code makes it easier to understand and analyze the impact of changes because requirements are traceable. Lower complexity and clearer design allow errors to be identified and fixed more quickly, enabling development teams to deliver updates and new features faster.
  • Smarter Testing Allocation: A testable architecture allows the application of the Testing Pyramid, enabling the prioritization of microflow testing (Unit and Integration) over slower and more expensive UI tests. This leads to faster test execution times and reduced complexity in test cases.
  • Simplified Learning Curve: A fixed structure provides guidance for new and junior employees (including citizen developers), allowing them to contribute to components like screens and navigation without introducing complexity or data errors into the core business logic.