Mendix Expert Developer: Testing, Quality Assurance and Troubleshooting

Testing, Quality Assurance and Troubleshooting

This domain tests whether you can prove the app works and diagnose it when it does not: model consistency, debugging, logging and layered automated testing.

Core rules

• Consistency errors block deployment; runtime errors appear only under real data. Run the model check before every commit and treat warnings as technical debt.
• The debugger lets you set breakpoints in microflows, step into and over sub-microflows, and inspect variables at each step. Use it to confirm which branch executes, not just whether an error occurs.
• Logging goes through Core.getLogger with a module-specific name and a level. Use warn/error for things an operator must see, debug/trace for diagnosis that stays off in production.
• Exceptions carry $latestError; log it with context and rethrow with rollback if the transaction is inconsistent.
• Test in layers: unit tests on rules and sub-microflows (the Unit Testing module, MxAsserts for invariants), integration tests against real services or stubs, and end-to-end tests through the UI.

Worked example

A production report of Concurrent modification on an order: two users opened the same object and both committed. The fix is not a retry loop. Re-retrieve the object inside the committing microflow, apply only the changed attributes, and enforce optimistic locking on the entity. For workflows where the first writer must win, introduce an explicit lock object with an expiry and release it in a finally-style path.

Traps

• Testing only through the UI, so business rules are never exercised in isolation.
• Logging at info level for every loop iteration and drowning the operator.
• Catching an exception, logging nothing, and returning a success path.
• Treating a consistency warning as harmless because the app still runs locally.