Showing posts with label E2E. Show all posts
Showing posts with label E2E. Show all posts

Monday, 12 October 2026

Mendix Testing Inside VS Code

 MendixWright: Mendix Testing Inside VS Code

MendixWright is a VS Code extension that lets Mendix teams check every environment and run Playwright regression tests without leaving the editor. Version 1.2.3 is out now, and this post walks through what it does, with annotated demo screenshots.

The problem

On most Mendix projects I work on, a simple question like "Is Acceptance up, and do the regression tests still pass?" can mean four tools. You open the Mendix Portal for environment status, a browser to sign in, a terminal for Playwright, and a spreadsheet to tie results back to requirements.

Each switch costs a few minutes and some context. Across a team running daily regression, that adds up fast. MendixWright brings it all into one VS Code panel.

What MendixWright is

MendixWright is the Mendix Testing Plugin for VS Code, published by KaizenFix. Search "Mendix" in the Extensions Marketplace, install it, and a Mendix Testing icon appears in the activity bar.


On first start, it checks for the Chromium build that its bundled Playwright uses, and for @playwright/test each Playwright project in your workspace. If anything is missing, it offers to install it for you.

Local Mendix servers

Open the panel and any Mendix app running on your machine is already listed. In the demo it picks up an app on port 8080 running Mendix 11.11.0, with no configuration.


For each local app, you get the URL, Mendix version, admin API port, response time, Java process ID, and bind address. That's everything you'd otherwise dig out of Studio Pro or Task Manager before pointing a test run at it.

Every Mendix Cloud environment in one tree

Below the local servers sits Mendix Cloud Environments: every licensed app you can see, each with its Production and Acceptance environments. A green dot means the environment is up, and each row shows its URL, response time and Mendix version.

Expand an environment, and you get two checks. Health is the platform status. Home page health checks that the app's home page is authenticating and working, so it catches an app that's "running" but serving errors.

App details holds the metadata you usually need from the Portal: App ID, technical contact, region, subdomain, licence, and whether the project is checked out on this machine. It also clearly tells you when your API key doesn't have permission to see an app's environments.

From health check to test run in one click

Click the link icon on any environment, and you get four actions: open it in a new browser window, copy the URL, run Playwright tests against this URL, or authenticate and save the session.

The last two are where the time savings are. Run Playwright Tests points your existing suite at that environment, so the same tests run against local, Acceptance or Production without editing config. Authenticate and Save Session signs you in to the Mendix app once and stores the session, so later runs skip the login step.

Beyond testing: requirements and reporting

Two more features close the loop between what the app should do and what the tests prove.

  • Documentation. MendixWright reads your app's model and generates a business requirements document (BRD): overview, user stories and acceptance criteria. Requirement IDs stay the same when you regenerate, so tests can reference them and stay valid as the app changes.
  • MendixFix Insights. Playwright runs, and BRDs are published to a shared dashboard, broken down by requirement, test runner and persona. Product owners and testers see coverage and results without opening VS Code.

Why use it

  • One place. Environment health, sign-in and regression runs all live in the editor where you already write tests.
  • Zero discovery work. Local apps and every licensed cloud environment appear without configuration.
  • Catch real outages. Home-page checks spot an app that's up but broken, not just a container that's running.
  • Same suite, any environment. Point your Playwright tests at local, Acceptance or Production from a menu.
  • Traceable quality. Stable requirement IDs and a shared Insights dashboard give stakeholders evidence, not just a green tick.

Thursday, 8 October 2026

Mendix VSIX for IDEs to do AI regression E2E testing

MendixWright is a free VS Code plug-in; please ask, and I'll email you a copy.

  • Documentation that matches the app, generated from the model rather than written by hand afterwards.
  • Regression coverage from day one, without hand-scripting each test.
  • Traceability from requirements to acceptance criteria to tests.
  • Built for Mendix developers, working in VS Code beside Studio Pro.

https://youtu.be/Z4r3jKSCyRY

Thursday, 9 July 2026

Azure Container Jobs with Docker containing E2E Playwright testing

Overview: I recently did a great project with Playwright to continuously test Canvas Apps.  This post outlines how I did it.

Reporting: Every test suite run and the tests inside are documented in SharePoint lists. p Below you can see for a project called feedback the tests that verify DTAP Canvas apps (Dev, Test, and Prod).

The Feedback app, in production, is showing the availability tests run recently
 

CI: I decided to use Azure Container Jobs to run the Playwright tests on a Docker image.


Jobs: The Docker image get params and starts the type of tests, the trigger uses cron timing.



Azure Container Job: Each time a job is called, a new instance is created. This means multiple jobs can run simultaneously, and on each job instance I get multiple COUs, so I spawn out 2-4 Playwright processes so the tests run faster.



Friday, 8 November 2024

Playwright series - Post 2 - Refactored TS code for Consciously verify Apps in Production

Overview: Create a function with Playwright tests that loops through all my production apps, logs in, and validates the Page title load on each app's home page.

Steps:

1. Create the spec.ts code that reads app.json to loop thru and validate sites

2. Record and Store the session state for all future test runs (Used for MFA in the tests runs)

3. Create an apps.json file containing URLs to open and validate


4. After running the test, you'll see that the 3 tests were completed successfully. In my case, there were 2 Power Apps with MFA enabled and an anonymous public website that had been checked.

Optional: 
Create short cuts to run your tests using PowerShell
PS C:\repos\PW> npx playwright test -g "Prod-CanvasApps" --project=chromium --headed

Next Steps:

Run continuously using the Azure Playwright Service.

=========================

Playwright Series

Playwright Post 1 - Overview of E2E testing using Playwright

Playwright Post 2 - Continuously Test/Monitor Canvas apps and website with MFA enabled (this post)

Playwright Post 3 - Add App Insights logging inside your Playwright tests 

Playwright Post 4 - 6 Min walkthru of Playwright testing with Azure Monitor

Playwright Post 5 - Understanding how playwright works

Playwright Post 6 - Unattended testing when secured with MFA 


Other Posts

Upgrading two C# Blazor web applications and verifying using Playwright - super fast 

Mendix - Part 2 - Diving deeper (E2E automation testing of Mendix using Playwright)

Low-code testing with playwright walkthru

Continiously Monitor Apps using Playwright with TS

Testing Canvasa apps with Playwright using C# (rather use TS, it's better)