Opening the hood: introducing apx-testkit for Oracle Apex
Opening the hood: introducing apx-testkit
We ended the last post by saying we weren’t ready to open the hood yet.
Now we are.
The project is called terally: We’re not ready to open the hood yet. We are now. The project is called apx-testkit. It’s open source, it’s on GitHub, and this post is a straightforward look at what it does, why we built it the way we did, where it’s still rough around the edges, and how you can help.
The one-sentence version
Point apx-testkit at your Oracle APEX 26.1+ application’s APEXlang export, and it generates a Playwright test suite that checks your pages load, your form fields round-trip correctly, and your buttons exist — without you writing a single CSS selector.
That’s the pitch.
Everything else in this post is really about why delivering on that promise is harder than it sounds, and why we think the implementation matters just as much as the end result.
Why we built it this way
In the last post, we talked about what APEXlang unlocked.
For the first time, a tool can understand what an APEX application is supposed to contain by reading its metadata instead of scraping a running application and trying to infer its structure.
That gives us a solid foundation. The interesting part is what we chose to build on top of it.
No LLMs in the generation pipeline
It would have been easy to hand an export to a language model and ask it to “write some Playwright tests.”
We deliberately didn’t.
apx-testkit is metadata in, templates out. The same input always produces byte-for-byte identical output, and we verify that in CI.
That means when generated tests change, it’s because your application changed — not because an AI model made different choices today than it did last week.
There’s a bit of irony here.
One of the reasons we built apx-testkit is to support AI coding agents working on APEX applications, yet we don’t use an LLM to generate the tests themselves.
That’s intentional.
The agent gets a stable, predictable foundation to build on, and can spend its reasoning where it adds value instead of regenerating boilerplate.
No raw CSS selectors
Generated tests never depend on scraped DOM structure.
Everything goes through documented apex.item() and apex.region() APIs or Playwright's accessible-role locators.
When Oracle inevitably changes the DOM, we update one shared component library instead of asking every user to rewrite hundreds of selectors.
We’d much rather maintain a single abstraction layer than thousands of brittle tests.
We don’t claim support until we’ve verified it
This is probably the principle we’re least willing to compromise on.
Every capability in the project falls into one of three categories:
- verified against a running APEX application
- verified from export data
- not implemented yet
That’s why our documentation includes unfinished features and known limitations alongside completed ones.
Get Satwik’s stories in your inbox
Join Medium for free to get updates from this writer.
A testing tool that quietly guesses what should work is more dangerous than one that openly says, “we haven’t solved this yet.”
Where the project stands today
apx-testkit is still pre-alpha, and we’d rather say that clearly than pretend otherwise.
Here’s what’s already working:
- A parser that converts an APEXlang export into a typed, lossless representation. Anything we don’t understand yet is preserved instead of silently discarded.
- A deterministic generator that produces page objects and smoke tests for every page in an application.
- A Playwright component library covering items, regions, Interactive Grid, Cards, Faceted Search, Chart, and several other APEX components, all built on documented APIs.
- An MCP server that lets AI coding agents — whether you’re using Cursor, Claude Code, GitHub Copilot, or something else — run the entire pipeline as part of their own workflow.
- A verification corpus of 46 structurally different Oracle APEX applications that we continuously use to validate the parser and generator.
There’s also plenty that isn’t finished.
Some components are represented in the parser but don’t yet have runtime assertions.
Some known bugs are documented but still waiting for fixes.
And the milestone we care about most hasn’t happened yet: seeing a second independent team point this at a production APEX application and tell us where it falls over.
That’s the feedback we’re looking for.
How you can help
The simplest way is to try it.
Run it against your application. See what works. See what doesn’t.
If something behaves differently than we’ve documented, please file an issue.
We’ve tried hard not to claim anything we haven’t verified, but every project has blind spots. We’d much rather discover one because someone reported it than keep believing something that’s wrong.
If you’re interested in contributing, we’d love that too.
The bar isn’t cleverness.
It’s evidence.
When we add support for a new component or assertion, we want to know it works against real exports and, wherever possible, a running application. The contribution guide walks through exactly what that looks like, and we’ve kept a list of well-scoped issues for people looking for a first contribution.
You also don’t need to be an Oracle APEX expert to help.
The project is still small enough that thoughtful bug reports, careful testing, documentation improvements, and good questions all make a real difference.
Everything — the source code, documentation, contribution guide, roadmap, and current list of known issues — is on GitHub.
Go kick the tires.
Next time we’ll cover something a little different.
We didn’t just use AI agents while building apx-testkit — we gave the project a small team of them, each with a specific role, clear responsibilities, and defined limits on what it could decide for itself.
We’ll talk about how that worked, what didn’t, and what we learned from treating AI agents more like collaborators than autocomplete.
