TestingOps.ai

Low-code platforms · Native connection

Mendix and TestingOps: model-aware test design

TestingOps reads your Mendix application model, including entities, validation rules, pages and the microflows those pages call, and gives its AI test agents that model as context for targeted test cases.

  • Native connection
  • Available
Request a demo
Connection
Native connection
Writes back
Nothing, it only reads
Last checked
7 Nov 2026

In short

Mendix and TestingOps in short

The Mendix connection lets TestingOps read an app's model through Mendix's own APIs with a personal access token. It turns the domain model, pages and the microflows they call into knowledge-base sections and structured model facts for the linked project.

AI test agents use those facts when they design scenarios and test cases, and can list model elements that no test case mentions yet. TestingOps never changes or commits to your app model.

You need a Mendix personal access token with the repository scope Mendix requires for a temporary working copy.

What it does

What it does for your testing

  1. 1

    Validation rules become test paths

    Input
    Entities with validation rules and their messages
    TestingOps
    Records each rule as a business-rule fact with its message and its place in the model
    Output
    Context for positive and negative test cases that check the exact message the app shows
  2. 2

    Pages become screen context

    Input
    Pages with their widget tree, field rules, buttons and allowed roles
    TestingOps
    Describes each page in order: data sources, inputs, required fields, conditional visibility and actions
    Output
    Screens agents can plan steps against, with locator hints to confirm in the running app
  3. 3

    Microflow decisions become branches

    Input
    Microflows called from pages
    TestingOps
    Lists their steps from start to end with decisions, outcomes and validation feedback
    Output
    Each decision outcome as a candidate path for a scenario
  4. 4

    Coverage gaps become visible

    Input
    The model facts and the project's existing test cases
    TestingOps
    Matches model elements against the text of existing cases
    Output
    A list of screens, rules and decisions no test case mentions yet

Step by step

How it works

  1. Connect with a personal access tokenSave a Mendix personal access token under Integrations → Platforms → Low-code platforms. TestingOps sends it with each call to Mendix and keeps it per connection.
  2. Link an app to a projectAdd the app as a knowledge source of the project: pick it from the list (when the token can read deployments) or paste its Mendix Portal link. You can limit the link to one module or a branch.
  3. TestingOps reads the modelEach sync checks the branch's latest commit first. When it changed, TestingOps opens a temporary working copy, reads the model with the Mendix Model SDK and deletes the copy. Nothing is committed.
  4. The model becomes test contextEntities, rules, pages and page-called microflows become knowledge-base sections and structured facts. Elements that disappear from the model are retired from the facts.
  5. Agents write and check test casesAgents start scenarios from the model facts, confirm each item in the running app and can list elements no case covers. The cases run like any other web test case on your execution provider.

There is no separate "generate tests from the Mendix model" button. Test cases are written by agents or by AI case generation, with the model as context.

Connect

Setup

  1. In the Mendix Portal, create a personal access token with the mx:modelrepository:repo:write scope, and mx:deployment:read if you want to pick apps from a list.
  2. In TestingOps, open Integrations → Platforms → Low-code platforms → Mendix and save the token.
  3. In the project's knowledge sources, add a low-code source and pick the app or paste its Mendix Portal link, optionally with a module or a branch.
  4. Select Sync now. Later syncs run automatically and skip the work when the branch has no new commit.
Where you connect it in TestingOps: Integrations → Platforms → Low-code platforms → Mendix

Use cases

Use cases

Build a first regression set for an existing app

Trigger
A team links its Mendix app to a new TestingOps project
Uses
Domain model, validation rules, pages and the microflows they call
Agent activity
Plans scenarios from each validation rule, field rule, access rule and decision outcome, then confirms them on screen
Result
Draft test cases that name the model element they come from
Condition
Cases are reviewed like any other agent output

See what a sprint's model changes left untested

Trigger
A new commit on the linked branch
Uses
The re-read model and the project's current test cases
Agent activity
Lists screens, rules and decisions that no test case mentions
Result
A gap list to plan new cases from
Condition
This is a text match against existing cases, not an analysis of which cases a model change breaks

Test role-based access

Trigger
Pages and entities with module-role access rules
Uses
Access rules per module role, including XPath constraints, and the roles allowed on each page
Agent activity
Writes cases that sign in as different roles and check what each role can see and change
Result
Access test cases tied to the rules in the model
Condition
Test accounts for each role must exist in the test environment

Capabilities

Capabilities and limits

What is read

  • Modules of the app (Marketplace and System modules are skipped), or one module, on the main branch or a branch you choose
  • Domain model: entities, attributes, enumerations, validation rules with their messages, associations and access rules per module role
  • Pages: title, URL, allowed roles, parameters, widget tree, field rules, buttons and data sources
  • Microflows called from pages: steps, decisions and outcomes, validation messages, object operations, calls and loops

What is produced

  • Knowledge-base sections for the linked project
  • Structured model facts: screens, business rules, access and field rules, decisions, validation messages and enumerations
  • A list of model elements no test case mentions, available to agents and through the API

Where it can write

Nothing in your Mendix app. TestingOps creates a temporary working copy to read the model and deletes it afterwards (Mendix removes it after 24 hours if deletion fails). It never commits.

How it connects

Mendix Repository API and Model SDK with your personal access token; the Deploy API only to list your apps

Account and permissions

  • A Mendix personal access token with the mx:modelrepository:repo:write scope, which Mendix requires to create a temporary working copy
  • Optionally mx:deployment:read, to pick apps from a list instead of pasting a link

Limits

  • Up to 120 entities, 80 pages and 60 microflows per sync, and 140 lines per page or microflow
  • Not read: nanoflow bodies, microflows that no page calls, workflows, scheduled events, service definitions, Java action code and navigation
  • Apps on your own Git server are not supported by Mendix's model API
  • Preparing a working copy can take a few minutes
  • No analysis yet that maps a model change to the existing test cases it affects
  • No automation script generation: test cases run as AI-executed steps

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team maintains an order-entry app in Mendix. After linking it, an agent finds that the Order entity requires a delivery date and that the microflow behind the Save button rejects past dates with the message "Delivery date cannot be in the past".

The agent drafts cases for a missing date, a past date and a valid date, each naming the rule and the microflow it comes from, and confirms the message on the running page before the cases go to review.

Frequently asked questions

Does TestingOps change my Mendix app?

No. It reads the model from a temporary working copy that it deletes after reading, and it never commits. If deleting the copy fails, Mendix removes it after 24 hours.

Why does the token need a write scope?

Mendix requires mx:modelrepository:repo:write to create a temporary working copy, which is the only way its Model SDK can read the model. TestingOps uses the token for that and for reading; it does not write to your repository.

Which parts of the model are read?

The domain model (entities, attributes, enumerations, validation rules, associations, access rules), pages and the microflows that pages call. Nanoflow bodies, microflows no page calls, workflows, scheduled events, service definitions and Java code are not read.

Does it generate test scripts or Mendix unit tests?

No. Agents write test cases whose steps are executed by AI on your execution provider. Page descriptions include Mendix widget locator hints that agents confirm in the running app.

Will it tell me which tests a model change breaks?

Not yet. A new commit makes TestingOps re-read the model and retire elements that are gone, and agents can list elements no case mentions. Change impact analysis currently works on code repositories, not on Mendix models.

How often is the model read?

When you select Sync now and automatically afterwards. If the branch has no new commit, nothing is opened or read again.

Next step

See what your Mendix model gives the agents: request a demo and bring a non-production app.

Request a demoMore low-code integrations