The test debt dilemma in mature Mendix apps

Why setting up tests by hand was the main reason teams fell behind

If you’ve been building apps in Mendix for a while, this story will sound familiar.

A project starts as a small internal tool. Over three or four years, it grows into a core business application with dozens of modules, complex billing logic, and multiple integrations. The app works, but test coverage is sparse. Whenever you need to refactor a core flow or prepare to upgrade from Mendix 9 to Mendix 10 or 11, everyone gets nervous because there is no reliable regression safety net.

Why didn’t the team build automated tests in the first place?

The honest answer: “it was just too much manual work.”

In MTA 3.1 and earlier, the test execution engine did its job well. It ran microflows directly and rolled back database transactions so test data didn’t pile up. But creating those tests meant clicking through the web UI for every single test case: adding steps, selecting entity types, and typing in parameter bindings and assertion rules one by one.

When you have a backlog full of new user stories, spending three months manually clicking through forms to set up regression tests is rarely an option. So test debt piled up.

When documentation is outdated, look at the model

How visual models give AI the context it actually needs

When designing tests, having clear user stories or acceptance criteria is always useful. If you have those documents, you can include them in your prompt so the AI understands what the feature was meant to do.

But in older Mendix apps, original documentation is often incomplete or outdated. In text-based stacks, missing documentation makes test generation risky because the AI has to guess what implicit code contracts mean.

In Mendix, you have a major advantage: “the visual model is the real source of truth.”

Every entity, attribute constraint, decision fork, and rule validation is explicitly defined in your .mpr project file. Using the Mendix CLI (mxcli), or the native Studio Pro MCP server available in Mendix 11.12 and higher, the AI can inspect the exact microflow structure in a read-only way:

1. It reads the microflow activities, loops, and decision splits directly from the model.
2. It identifies the happy paths, error conditions, and boundary values.
3. It sets up working test cases in MTA with proper assertions.

This makes it practical to build regression tests for older Mendix 9 or 10 apps before starting a major upgrade to Mendix 10 or 11.

Sensible economics: generate once, run forever

Keeping AI costs low and test runs fast

Using AI shouldn’t mean taking on unpredictable monthly subscription bills or high token costs:

• No AI needed for CI/CD runs: You use your AI assistant “once” during development to generate the test cases. Once saved in MTA, your tests run natively at compiled speed in your CI/CD pipelines with “zero ongoing AI token costs.”
• Two-tier model strategy: You can use a smart reasoning model (like Claude Sonnet or Gemini Pro) to analyze the logic and plan the test, then let a fast, inexpensive model (like Gemini Flash or Claude Haiku) execute the tool calls to configure the steps in MTA.