Alumnium: an AI layer over Selenium, Playwright and Appium that turns test steps into plain English
End-to-End Testing with AI for Agents and Engineers
At a glance
- What is it?
- Alumnium wraps an existing WebDriver or Playwright session and exposes act, check and get methods that accept natural language. It is a thin orchestration layer, not a replacement for your driver, and the TypeScript package is the least documented of the three language bindings.
- Who is it for?
- Adopt Alumnium if you already have a working Selenium, Playwright or Appium setup and want to replace brittle locator chains with intent-level steps, and if your team can accept nondeterministic runs and a per-call model cost. Do not adopt it as a replacement for a driver, as a way to test without a real browser session, or as a way to keep test suites offline.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Alumnium targets: locator drift in end-to-end suites
End-to-end tests break for reasons that have nothing to do with the application being wrong. A button gets a new CSS class, a wrapper div appears, an id changes from submit-btn to submit, and the test fails before it ever exercises the behaviour it was written to check. The Alumnium README frames the project as building on the existing automation ecosystem while simplifying interactions with applications and providing what it calls more robust mechanisms for verifying assertions. The README's own example is a search flow: type a query into a field, press Enter, then assert on the page title and on the presence of a result domain. In a conventional Selenium test those two assertions would be written against specific selectors or XPath expressions. In Alumnium they are written as strings. The audience is therefore narrow and identifiable: engineers who already run Selenium, Playwright or Appium and who are willing to trade deterministic steps for intent-level ones. It is not aimed at teams with no automation harness at all, because the library is constructed around a driver object that you supply.
How the act, check and get methods relate to your driver
The architecture visible in the README is a wrapper, not a runtime. You construct a driver yourself (ChromeDriver in the Java sample, Chrome in the Python sample, a selenium-webdriver Builder in the TypeScript sample), navigate it to a URL, and then pass it into the Alumni constructor. From that point the driver still does the work; Alumnium supplies the vocabulary. Three methods carry the whole interface. do (act in Java) takes an instruction such as typing text into a field and pressing Enter. check takes an assertion expressed as a sentence, for example that the page title contains a string or that the results contain a domain. get takes a question and returns a value, which the Python and TypeScript samples compare against 34 for the query atomic number. The data flow is therefore: natural-language instruction in, driver actions out, with the library deciding which elements to touch. That decision is the part the README does not describe. Nothing in the supplied material explains how the model receives page state, whether it is a DOM snapshot, an accessibility tree, or a screenshot, and that omission matters because it determines what kinds of pages the library can handle at all.
Installation paths differ sharply by language
Python and TypeScript are one-liners: pip install alumnium and npm install alumnium. Java is not. The Gradle snippet declares a testImplementation dependency on ai.alumnium:alumnium plus a testRuntimeOnly dependency on a platform-specific CLI artifact, shown as ai.alumnium:alumnium-cli-darwin-arm64, with the README noting that other platforms must be added as needed. That structure implies the Java binding shells out to a native binary rather than running entirely in the JVM, and it means a Java build is not portable until someone enumerates the target platforms in the build file. The MCP route is separate again: a curl command piped to sh from alumnium.ai/install.sh, followed by registering the server with an agent, shown here as claude mcp add alumnium --env OPENAI_API_KEY=... -- alumnium mcp. Note the environment variable in every example: OPENAI_API_KEY, set in the shell, in os.environ, or via process.env. The README does not document alternative providers, so treat the model backend as a fixed dependency unless the linked configuration documentation says otherwise.
The MCP mode is a different product from the library
Alumnium ships two things that share a name. One is a library you import into a test file and drive with explicit do, check and get calls. The other is an MCP server you register with an agent, after which the quick start is two steps: run your agent, then tell it to open the URL and test your application. The second mode has no test file, no assertions checked into version control, and no obvious artifact at the end. That is a real difference in what you get. A library test is reproducible in the sense that the same script runs again; an agent-driven session is a conversation whose result you have to read. Teams that need a pass or fail signal in CI should look at the library bindings, not the MCP path. The MCP path is better suited to exploratory checks during development, where a human is present to judge whether the agent actually verified anything.
Where this approach breaks down
The obvious failure mode is cost and latency. Every do, check and get call is a model call, and the Python sample makes four of them in a single short test against a search page. A suite of a few hundred tests, each with several steps, multiplies that. The README offers no caching, no record-and-replay mode, and no offline fallback, so a network outage at the provider becomes a test outage. The second problem is determinism. A selector-based assertion either matches or it does not. A sentence-based assertion is evaluated by a model, which means the same page can produce different verdicts across runs, and a flaky AI assertion is harder to debug than a flaky selector because the failure message is a sentence rather than an element path. The third problem is scope. The README's examples are all web pages reached through a browser driver. Appium is listed as a supported driver, but nothing in the supplied material shows a mobile example, so anyone planning to use Alumnium for native app testing is working from an unverified claim. Finally, the library assumes you already have working driver setup, page navigation and teardown. It removes the locator problem, not the harness problem.
Compared with a self-hosted browser agent such as browser-use
The closest alternative in kind is a browser agent library that drives a browser directly from a model, with no WebDriver underneath. The difference is where the session lives. A browser-use style tool owns the browser: it launches it, decides what to click, and reports back. Alumnium does the opposite. It takes a driver you created, in a process you control, using the framework your team already runs in CI, and only replaces the step definitions. That matters for adoption cost. You keep your existing grid, your existing browser matrix, your existing reporting, and you change how individual steps are written. You also keep the ability to drop back to raw Selenium calls for the steps that need to be exact, which a browser-owning agent does not offer in the same way. The trade is that Alumnium inherits every constraint of the driver it wraps, including the ones that made you consider an agent in the first place.
Versioning, licence and what maintenance actually costs
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive and carries no copyleft obligation on your test code, but it also means no warranty and no support commitment from the maintainers. The release history shows 0.22.0 in September 2026, 0.21.0 in June 2026, and an alpha 0.22.0-alpha.1 five days before the stable release. A pre-1.0 project on that cadence will change behaviour between minor versions, so pinning exact versions in your build file is the practical move rather than accepting ranges. The Java dependency makes this sharper: the CLI artifact is versioned alongside the library, and the README's snippet pins both at 0.21.0 while the current release is 0.22.0, so the example itself is already behind. Budget for reading release notes before each bump, and for the per-call model spend as a recurring line item rather than a one-time integration cost. This is a description of the licence terms, not legal advice; check how MIT interacts with your own distribution model before shipping anything derived from it.
Editorial conclusion
Adopt Alumnium if you already have a working Selenium, Playwright or Appium setup and want to replace brittle locator chains with intent-level steps, and if your team can accept nondeterministic runs and a per-call model cost. Do not adopt it as a replacement for a driver, as a way to test without a real browser session, or as a way to keep test suites offline. Before committing, verify three things: that your chosen binding (Java, Python or TypeScript) is documented well enough for your team, that your CI environment can reach the model provider, and that the version you pin actually ships the platform-specific CLI artifact your machine needs, since the Java install example lists alumnium-cli-darwin-arm64 explicitly and says other platforms must be added separately.
Community notes