Generating Autotests and Locators with AI on a Legacy Project: Hands-On Experience

The author continues her hands-on series on test autogeneration. In the new article, she walks through exactly how she generated autotests and locators for a large legacy project, how much time it took, where the model made mistakes, and whether it was worth it.

What the previous part of the series showed

The author's previous article had already established the key takeaway: without a README describing the test framework's architecture, generating autotests on a large legacy project turns into an endless cycle of reviews and fixes. Without context on how the framework works — which base classes to use, how locators are organized, which conventions the project follows — the model keeps proposing code that has to be rewritten by hand instead of producing a working result right away.

That takeaway frames the new piece: once the basic prerequisite — an architecture description — is in place, the question becomes one of practice. This is where the author starts the new article, promising to show not abstract advice but a concrete process for generating autotests and locators on real code.

Where locator generation usually stumbles

Locators are arguably the weakest point of UI test autogeneration. They depend on a page's specific markup, which in legacy projects is often unstable, inconsistent, and undocumented. A model that generates locators without a deep understanding of a given screen's actual DOM structure risks proposing brittle selectors — ones that break at the slightest layout change, or that duplicate locators already in the project instead of reusing them.

That's why the author focuses the new article on three practical questions: how much time this approach actually saves compared with writing tests by hand, in which scenarios the model keeps making mistakes even with an architecture README, and whether it pays off at the scale of a large legacy project, where the cost of test errors is false CI failures and team time lost to triage.

• Format — the second article in a series on generating autotests and locators with AI
• Prerequisite from the first article — a README describing the framework architecture is mandatory for a legacy project
• Focus of the new article — the concrete process, time spent, and the model's typical mistakes
• System under test — a large legacy project

What it means

The experience from series like this one shows that, in practice, AI-generated autotests don't boil down to a simple "ask and get working code." They require upfront work on project context and a sober assessment of where the time savings are real and where they're offset by manual review and rework of the generated code.