9.3 Consistency Checks, Best Practices & Quality

9.3 Consistency Checks, Best Practices & Quality

Exam Focus: The Mendix platform embeds quality assurance directly into the visual modeling experience. For the Intermediate Developer exam, you must master the difference between blocking compiler Errors and non-blocking Warnings in the Error List, leverage MxAssist Logic Bot and MxAssist Performance Bot to eliminate performance antipatterns (such as commits and retrieves inside loops), and structure automated tests using the Mendix Unit Testing module.

In traditional development, architectural antipatterns and syntax errors are often uncovered late in the delivery cycle during integration testing or production outages. The Mendix platform prevents defect leakage through a multi-tiered quality framework: instantaneous real-time consistency checking, AI-assisted modeling governance, automated static model analysis via MxAssist Performance Bot, and an embedded unit testing framework.

---

Studio Pro Error List & Real-Time Consistency Engine

Unlike traditional text-based programming environments where developers write code and initiate explicit compile cycles, Mendix Studio Pro incorporates a real-time model compiler. Every modification made to a domain entity, microflow, nanoflow, page widget, or security role immediately triggers the consistency engine in the background.

Classification of Compiler Diagnostics

The Error List pane in Studio Pro organizes diagnostic messages into three distinct tabs:

1. Errors (Blocking Compiler Faults)

• Visual Marker: Red circle with an 'X'.
• Impact on Execution: Absolute Blocker. A Mendix application cannot be run locally (F5) and deployment packages cannot be generated on Team Server until the error count is exactly 0.
• Typical Triggers:
  • A sub-microflow call missing a required input parameter.
  • An invalid XPath constraint expression containing syntax errors or referencing non-existent attributes.
  • An entity with missing Read/Write entity access rules when Project Security is set to Production.
  • A microflow decision split missing an outgoing sequence flow for an enumeration value or boolean branch.
  • An entity attribute data type mismatch in a Change Object activity.

2. Warnings (Non-Blocking Quality Alerts)

• Visual Marker: Yellow triangle with an exclamation mark.
• Impact on Execution: Non-blocking. The application can run locally and deploy to the cloud with active warnings. However, enterprise delivery standards mandate resolving warnings prior to release.
• Typical Triggers:
  • Unused application artifacts (e.g., an orphaned microflow or page that is never called from navigation, buttons, or parent flows).
  • An entity attribute marked as mandatory without a default value in an uncommitted non-persistable entity.
  • An XPath constraint that may result in suboptimal database table scanning.

3. Deprecations (Platform Lifecycle Notices)

• Visual Marker: Information symbol (blue circle with 'i').
• Impact on Execution: Non-blocking. Informs the developer that a widget, Java action, or runtime library will be removed in a future major platform release, providing migration guidance.

Mendix Assist: Logic Bot and Performance Bot

Mendix Assist is delivered as two bots inside Studio Pro. Learn both names precisely — "Quality Bot" and "Best Practice Recommender" are invented labels that circulate in third-party study material but appear neither in the product nor in the documentation:

MxAssist Logic Bot

An AI-powered virtual co-developer that helps you model microflow logic:

• Next best action suggestion — recommends the top five next activities out of more than 40 options, at roughly 95% accuracy.
• Auto-configuration — pre-populates the parameters of the activity it suggests.
• Contextual suggestions — derives context by looking left and right when you insert an activity mid-flow, and from the page the microflow is called from.
• It is built on machine-learning analysis of over twelve million anonymized microflows, is enabled by default, and appears as a blue dot in the flow. Its settings live under Edit > Preferences > Mendix Assist > Logic Bot.

MxAssist Performance Bot

A model-inspection bot that checks your app against Mendix development best practice. It operates at three levels of assistance:

1. Detection — inspects the model, identifies the issue, and points you to the exact document or element causing it, plus everything affected by it.
2. Recommendation — explains the issue, its potential impact, and how to fix it, linking to a step-by-step best-practice guide.
3. Auto-fixing — in many cases implements the best practice and refactors the model for you, once you acknowledge it.

The MxAssist Performance Bot pane provides Inspect now, Limit to current tab, Export (recommendations to CSV, excluding suppressed items), and Configuration. The Configuration dialog has an App Model tab, where you choose which modules or documents to inspect, and a Best Practice tab, where you choose which best practices to inspect against.

What the Performance Bot Inspects

It is built from statistical analysis of thousands of anonymized Mendix apps plus Mendix Expert Services best practice, and it covers antipatterns across microflows, domain models, pages, and security. Many teams make a clean Performance Bot run part of their definition of done, precisely because it catches the database antipatterns below before code review does.

Standard Mendix Naming Conventions Enforced by Quality Audits

---

Critical Performance Antipatterns Detected by MxAssist Performance Bot

The application-quality material the Intermediate Developer exam returns to most often is database antipatterns in microflows:

Antipattern 1: Commits Inside Loops

• The Flaw: Placing a Commit object activity inside a For each loop that processes a list of entities.
• Technical Impact: If the loop processes 1,000 entities, the application opens and closes 1,000 discrete database transactions, triggers before/after commit event handlers 1,000 times, writes to the disk transaction log 1,000 times, and initiates 1,000 client synchronization events. This degrades performance from milliseconds to minutes and risks database deadlock.
• Remediation:
  1. Inside the loop, change attributes using a Change object activity with Commit: No.
  2. Use an Add to list action to append the modified entity to a newly created $ModifiedList variable.
  3. Place a single Commit list activity outside and immediately following the loop. This commits all 1,000 records in a single optimized relational database batch statement.

Antipattern 2: Database Retrieves Inside Loops (The N+1 Query Problem)

• The Flaw: Executing a database Retrieve activity inside a loop to fetch an associated entity for each iteration.
• Technical Impact: Known as the N+1 query antipattern. Iterating over N items executes N separate SQL SELECT statements across the network, generating massive database latency and saturating the ConnectionBus pool.
• Remediation:
  1. Batch Retrieve: Before entering the loop, retrieve all necessary related records in a single batch query using an XPath constraint or association retrieval.
  2. In-Memory Operations: Inside the loop, use the Filter list or Find in list list operations to locate the associated item in memory without issuing SQL queries.

Antipattern 3: Unconstrained Database Retrieves

• The Flaw: Using a database Retrieve action without an XPath constraint or without limit/offset pagination on an entity that grows over time (such as AuditLog or TransactionHistory).
• Technical Impact: Fetches hundreds of thousands of rows into server RAM, causing OutOfMemoryError and application crashes.

---

Automated Testing with the Mendix Unit Testing Module

Enterprise quality assurance requires automated regression testing. The Unit Testing module (available from the Mendix Marketplace) lets you test microflows, Java actions, and other logic from inside the running app.

Setting the Module Up

1. Import the module and give the TestRunner module role to every user role that should be able to run and view tests.
2. Configure the module's Startup microflow as (or inside) the app's after startup microflow.
3. Add the UnitTestOverview microflow to navigation, or place the UnitTestOverview snippet at the top level of a custom page.
4. By default the module is enabled only for local development; set the UnitTesting.Enabled constant to true to run tests in a deployed environment. Mendix recommends leaving it false in production.

Anatomy of a Microflow Unit Test

To be recognised by the test runner, a test microflow must satisfy a precise contract — and each clause is a favourite exam distractor:

The optional UnitTestContext object gives the microflow access to the test's name and to the results of earlier assertions — useful when a single test contains several assertions and later logic depends on how the earlier ones turned out.

Assertions and Reporting

• Assert using expression is the assertion action. Its parameters are Name (shown in the timeline), Expression (must evaluate to a Boolean), FailureMessage (include the actual and expected values), and StopOnFailure (true aborts the test immediately, false continues so the remaining assertions still run). A failed assertion always fails the test either way.
• Report step logs a key step of the execution into the same timeline, and that timeline is what you read when diagnosing a failure.

Setup and TearDown

Two specially named microflows run once per test run — not once per test:

• A microflow named exactly Setup in the module is invoked at the beginning of each test run.
• A microflow named exactly TearDown in the module is invoked at the end of each test run.

Exam Trap: The names are Setup and TearDown with no prefix or suffix, and they fire once per run, whether that run contains one test or fifty. Answers describing TestSetup_/TestTearDown_ microflows that execute before and after every individual test are describing JUnit's @Before/@After, not the Mendix microflow contract.

Rollback Isolation

Exam Key Concept: By default, all changes made while running a microflow test — objects created and objects changed — are rolled back at the end of the test run. Each test suite exposes a Rollback microflow tests after execution checkbox that controls this for that suite only. Clearing it saves the test data to the database, which is why Mendix's stated best practice is to leave it checked unless you have a specific reason not to.

JUnit Tests for Java Code

The same module discovers JUnit 4 tests in javasource/<yourmodule>. A Java method is recognised as a test when it is public, non-static, parameter-less, and annotated with org.junit.Test; @Before, @After, @BeforeClass, and @AfterClass behave exactly as JUnit defines them. Set the UnitTesting.FindJUnitTests constant to false to exclude them.

Running Tests from a Pipeline

The module ships a remote API — disabled by default — for CI/CD. Set UnitTesting.RemoteApiEnabled to true and supply a value for UnitTesting.RemoteApiPassword (without a password the API stays disabled), then POST to unittests/start to launch a run and poll unittests/status for completed, tests, failures, and failed_tests.

Functional End-to-End Testing: Application Test Suite (ATS) Basics

While the UnitTesting module validates server-side microflow business logic and domain rules, functional user experience testing requires automating the browser UI.

Why Generic Selenium Fails with Low-Code Applications

Traditional automated testing tools (such as raw Selenium WebDriver) struggle with modern single-page Mendix web applications:

• Dynamic DOM IDs: Mendix generates dynamic, non-deterministic HTML element identifiers (e.g., mxui_widget_TextInput_3) that change on every deployment or page re-render.
• Asynchronous AJAX / Promise Settlements: Mendix pages load asynchronously via microflow data sources. Standard test scripts execute too quickly, attempting to click buttons before asynchronous client-side promises resolve, resulting in NoSuchElementException.

The Mendix Application Test Suite (ATS)

Mendix ATS is a specialized test automation framework built specifically for the Mendix platform. Know its current commercial status before you recommend it: Mendix no longer sells new ATS licenses, though it remains a supported product for existing customers with active contracts. New teams therefore standardise on the Unit Testing module for logic plus a general-purpose UI automation tool, while ATS stays in use where it is already licensed. Its distinguishing characteristics are:

• Widget-Aware Page Object Model: ATS understands the internal architecture of Atlas UI widgets (such as Data Views, Data Grids, Dropdowns, and Tab Containers). Instead of querying fragile CSS paths or dynamic element IDs, ATS targets widgets by their Studio Pro name (e.g., grid_Orders).
• Automatic Synchronization: ATS automatically listens to the Mendix client-side runtime communication bus, waiting for microflows and background network calls to finish before asserting UI states or executing clicks.
• Keyword-Driven Authoring: QA engineers can author and maintain automated test scripts without writing raw Java or JavaScript code.
• CI/CD Pipeline Integration: ATS test suites can be triggered automatically via webhooks or REST APIs within automated build and deployment pipelines (such as Jenkins, Azure DevOps, or GitHub Actions) before promoting builds to Production.