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.

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

OWASP API Risks Updated - BOLA

As AI use and sophistication grow, BOLA attacks have risen rapidly.  Broken Object Level Authorisation (BOLA) is when an authenticated user can switch parameters like the URL in an API request and access other users' data. For example, GET https://api.example.com?client=32 returns the authenticated user's information, such as your age or other PII.

The authenticated user changes the client to "33"; I now get someone else's records, as the API only checks that I am an authenticated user, not that I am authorised to check another client.

Action	URL	Result
GET	https://api.example.com?client=32	The user sends valid authentication for their own client.  The result returns their data.  Correct.
GET	https://api.example.com?client=33	The user sends valid authentication for their own client data but requests another client's info.  The result returns the other client's private data.  Incorrect behaviour.  Major security issue.

Tools like Wiz and StackHawk will pick up BOLA API weaknesses.

Using StackHawk for DAST and API Security Testing on Azure

I recently started using StackHawk, and I am impressed with the tooling.  Its DAST and API security testing are outstanding, and it integrates beautifully with VS Code.

Application security requires more than simple source code scanning. While SAST, SCA, and secrets scanning are great in CI pipelines, key vulnerabilities remain hidden until an application is running. This is where Dynamic Application Security Testing (DAST) becomes essential.

In my development environment, Claude and GitHub Copilot are building my code and do so much of the Static Application Security Testing (SAST) 7I don't feel compelled to use them in the IDE.  Claude does a great job; it can do SAST and implement security best practices extremely well.

Software Composition Analysis (SCA) focuses on the third-party and open-source components our code relies on.  Claude once again does a great job of identifying vulnerabilities and upgrading to the latest versions.

Security secrets: Claude once again does a great job, especially with remote repo integrations such as GitHub, ADO, and GitLab.

Conclusion:

For enterprises building Azure-hosted web applications and APIs, StackHawk offers a developer-focused DAST approach that integrates directly into modern DevSecOps workflows. Unlike traditional DAST tools, which security teams often operate, StackHawk is designed to work with developers, providing rapid feedback during testing and deployment.  This "shift left" saves time and money. There are various DAST options, but StackHawk has become my favourite.  With the rise of AI coding, developer-level DAST is more important than ever.

BURP has been the standard for pen testing for many years.   Three DAST tools focus on different things: Burp Scanner, OWASP ZAP, and StackHawk.
Wiz API is a great test tool for API Security: runtime security, covering much of the same area as StackHawk for API security, but its key differentiator is runtime threat detection.

Native Mobile App Development Notes

Overview: Many approaches exist for building and deploying native apps to the App Store (Apple) and Play Store (Android).  This post shows an approach that works well for converting a React web app into a Play Store app using the Expo toolchain.  The choice remaining is whether to use a wrapper or port the code to native UI. 

EXPO, as a company, has two independent products that work together nicely for mobile apps.

At one of my businesses, we are using the approach below successfully to deploy the core SaaS app onto the stores:

Using Expo products to build and deploy native Apps onto the two main public stores using a wrapper or native approach) 

An Introduction to Microsoft Azure SRE Agent

Managing cloud environments often involves jumping between alerts, logs, dashboards, and code repositories when something breaks.  Azure SRE Agent aims to simplify operational troubleshooting.  The tool:

1. Investigate incidents
2. Automates routine workflows
3. Helps resolve issues faster

What is the Azure SRE Agent?

The SRE Agent combines 1) Brain - Large Language Models (LLMs, either OpenAI or Anthropic models) with 2) Azure-specific product knowledge - tools and knowledge, and 3) Instructions - custom configuration.  Allowing it to reason over operation support data.

The agent is deployed directly inside an Azure Resource Group, which sits within an Azure Subscription.  I have only used the Reader Scope for my assigned identity permissions; it can operate in Reader Scope (for inspection and telemetry analysis) or Privileged Scope (to execute changes and automated mitigations).

The Azure SRE Agent operates across three main operational patterns

Automate Incidents: When an alert fires, the agent queries monitoring platforms, correlates signals across systems, determines probable root causes, and suggests or executes fixes

Automate Scheduled Workflows: It can perform scheduled background tasks, such as routine health checks and compliance sweeps

Investigate and Advise (Virtual Team Member): Engineers can ask natural-language questions (e.g., "what changed in the last hour?") in chat interfaces like Microsoft Teams to get grounded operational insights.

Running Incident Response Issues

Instead of forcing engineers to manually correlate disparate data, the agent follows a streamlined incident workflow: when an alert fires (in Azure Monitor, in my case), the SRE agent picks it up.  It queries logs using correlation IDs to connect the data so that the agent can do the Root Cause Analysis & Ticketing: The agent identifies the probable cause (such as a bad commit or memory trend) and can prefill an incident ticket in ServiceNow or PagerDuty with diagnostic findings

The support engineer, in this case me, reviews and approves the remediation.

Connects natively with Azure Monitor, Application Insights, Log Analytics, PagerDuty, ServiceNow, GitHub, and Azure DevOps

Tip: External tools can also connect via the Model Context Protocol (MCP), basically making any API accessible.

Customisation: Capabilities can be extended using Skills (Azure CLI scripts and marketplace runbooks), Python tools, Custom sub-agents, and Agent hooks

Billing: Operational reasoning is metered using Agentic Units (AUs) rather than standard raw tokens, with standard monthly allocations; I still have no idea what this will cost or how it is calculated.

Summary

The Microsoft Azure SRE Agent provides a structured, governed way to use AI for incident management. By pulling together context from observability tools and code repositories into a single thread, it reduces tool switching and speeds resolution.

Create a single View of all your tenants subscriptions - easily identify Azure Credit availability

One Azure Dashboard for all Subscriptions in Your Azure Tenant

A production subscription. A development environment. A Microsoft for Startups sponsorship. Perhaps a Visual Studio subscription, a trial subscription, or a subscription dedicated to experimentation.

The information you need is scattered across Azure:

💰 Cost Management for spend
📦 Resource Graph for inventory
💳 Billing for credits and subscriptions
🔍 Individual subscription pages for everything else

I wanted a single place to answer three simple questions:

✅ What is running?
✅ What is it costing?
✅ How much Azure credit is left?

This solution creates an Azure Portal dashboard covering every subscription in a tenant.  Barclays Eagle Labs is amazing for startups, and they have helped me immensely, including getting Microsoft Startup Credits, and I think this will help a lot of people with their Startups.

What the dashboard shows

• Monthly cost per subscription
• Resource counts by subscription
• Resources grouped by type
• Complete resource inventory across all subscriptions
• Subscription offer type (Pay-As-You-Go, Sponsorship, Visual Studio, etc.)
• Billing account details
• Remaining Azure credit and expiry dates where available
• Direct links into Subscription Overview and Cost Analysis

Deployment in Four steps

1. Download the file:

• New-SubscriptionsDashboard.ps1

2. Open Azure Cloud Shell and select PowerShell

3. Upload the New-SubscriptionsDashboard.ps1 file into your Cloud Shell home directory

4. Get your tenant ID, set the dashboard location and run the creation PowerShell script:

PS> $tenant = (az account show --query tenantId -o tsv)

PS> $region = "uksouth"   // Set your region for the new dashboard

PS> ./New-SubscriptionsDashboard.ps1 -Tenant $tenant -Location $region

5. Open the dashboard URL returned by the deployment.

Why I like this approach

The dashboard continuously updates resource inventory, resource counts and subscription costs using Azure Resource Graph and Cost Management, while also providing a snapshot of credit balances and billing information.

For organisations using multiple subscriptions, especially Azure Sponsorship or Microsoft for Startups credits, this gives a genuine single pane of glass across the entire tenant. No more jumping between Cost Management, Billing, Resource Graph and Subscription Overview pages. One dashboard. One view.