Automated test generator

A tiny social post this week pointed to a tool called assrt. The pitch was simple: aim it at a web app, let it crawl, and get tests back. The post barely traveled. It picked up only a couple of likes. But the idea underneath it is bigger than the post. A new layer of testing tools is trying to do for end-to-end suites what code generators did for boilerplate: create a first draft fast enough that teams will actually start. Assrt’s public GitHub repo describes it as an AI-powered framework built on Playwright that can “discover scenarios automatically,” with a quick-start command that tells it to “discover” a target URL. (github.com) That matters because end-to-end testing has always had an ugly entry cost. A team can know it needs browser-level coverage and still put it off for months. Every useful test has to be written against real screens, real flows, and real selectors. Then the UI shifts and the suite starts to rot. Playwright itself has long offered a code generator, but that tool records the path a human takes through the app. You click around, and it writes the script. It is helpful. It is also fundamentally manual. (playwright.dev) Crawler-based generation changes the starting point. Instead of waiting for a tester to choose each path, the software explores the app on its own. That idea is not new. Crawljax, an older open source project, was built to crawl modern JavaScript-heavy web apps and map the DOM states and event transitions it finds. What is new is the packaging. Tools like assrt are taking that old crawling concept, bolting it to modern browser automation, and then adding language-model features on top. The result is less like a recorder and more like an intern that wanders through the product, writes down what it saw, and hands you runnable code. (github.com) That shift is showing up in the mainstream tooling too. Playwright now has official “Test Agents” that split the work into roles: a planner that explores the app and drafts a test plan, a generator that turns that plan into Playwright tests, and a healer that repairs failures when the UI changes. Playwright also exposes an MCP server so AI clients can interact with pages through structured accessibility snapshots rather than raw screenshots. This is the same broad move as assrt, even if the product shape is different. The browser is no longer just a place where tests run. It is becoming a surface that software can inspect, reason over, and use to propose coverage. (playwright.dev) Cypress is pushing from a neighboring direction. Its UI Coverage product maps which interactive elements were touched during tests and which were not. From there, Cypress says teams can generate targeted tests from those uncovered gaps. That is a slightly different workflow. It starts with visibility into missing coverage, not autonomous exploration. But it points to the same destination: less time spent hand-authoring the first 50 percent of a suite, and more time deciding which flows are actually worth keeping. (docs.cypress.io) The catch is that generated tests are only a baseline. A crawler can find pages, buttons, forms, and obvious paths. It cannot know your real business risks unless someone teaches it. It may miss hidden states, permission edges, payment failures, or the one brittle workflow that matters most. Even the official generators are framed as ways to get started quickly, not as substitutes for careful test design. That is why the interesting part of assrt is not that it can write tests from a crawl. Plenty of tools can now do some version of that. The interesting part is that the public repo is almost bare, the organization has just one public repository, and the quick start is still only three words long: `assrt discover (github.com)