APEX 26.1 Just Gave Testing a Free Hand
For years, testing an Oracle APEX application meant one of two things: a human clicking through every page before a release, or a script held together with brittle CSS selectors that broke the moment a theme update touched a <div>. Neither scales. Neither survives an app that changes weekly.
APEX 26.1 quietly changed the equation. With APEXlang, an application’s structure — its pages, regions, items, buttons, the whole shape of the thing — now exists as clean, human-readable, version-controllable text. Oracle built it so developers, and AI coding assistants, could read and edit apps like any other codebase. What’s less talked about is what it unlocks on the testing side.
Get Satwik’s stories in your inbox
Join Medium for free to get updates from this writer.
For the first time, a tool can know what a page is supposed to contain without scraping the DOM, guessing at selectors, or reverse-engineering a running app.
That’s a free hand we haven’t had before
When test tooling can read an app’s real structure instead of inferring it, testing stops being a chore that lags behind development and starts being something that can keep pace with it — even pace with an AI agent editing pages directly, which is very much the world we’re heading into.
We’ve been quietly building in this space: tooling that takes advantage of APEXlang to generate real test coverage from an app’s actual structure, and keeps it honest as the app evolves — so a change to a page shows up as a reviewable diff, not a silent regression discovered three sprints later.
It’s early. We’re not ready to open the hood yet, but the short version is this: APEX 26.1 didn’t just make apps easier to read — it made them easier to trust. We intend to make the most of that.
