Generating Automated Tests and Locators with Neural Networks on Legacy Projects: Practical Experience

The author continues a practical series about auto-generating tests: in the new article, she breaks down exactly how she generated auto tests 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

In the previous article by the same author, a key conclusion was already established: without a README describing the architecture of the test framework, generating auto tests on a large legacy project turns into an endless cycle of reviews and fixes. A model without context about the framework's structure — which base classes to use, how locators are organized, what conventions are adopted in the project — repeatedly suggests code that has to be rewritten manually instead of getting a working result right away.

This conclusion sets the frame for the new material: if the basic requirement — a description of the architecture — is met, then the question becomes one of practice. This is where the author starts the new article, promising to show not abstract tips, but a concrete process of generating auto tests and locators on real code.

Where locator generation usually stumbles

Locators are perhaps the most vulnerable part of UI test auto-generation: they're tied to the specific markup of a page, which in legacy projects is often unstable, inconsistent, and undocumented. A model generating locators without deep understanding of the actual DOM structure of a specific screen risks suggesting fragile selectors — ones that break easily with minor layout changes, or duplicate existing locators in the project instead of reusing ready-made ones.

This is exactly why the author focuses on three practical questions in the new article: how much time such an approach actually saves compared to manual writing, in what scenarios the model continues to make mistakes even with a README describing the architecture, and whether it pays for itself at the scale of a large legacy project where the cost of an error in tests — false CI triggers and lost team time in debugging.

• Format — the second article in a series about auto-generating tests and locators with AI
• Condition from the first article — README describing the framework architecture is required for a legacy project
• Focus of the new article — concrete process, time spent, and typical model errors
• Object of testing — a large legacy project

What this means

Experience from similar article series shows: auto-generating tests with AI in practice doesn't reduce to a simple "asked — got working code." It requires preparatory work with project context and a sober assessment of which scenarios deliver real time savings and which ones are offset by manual review and reworking of the generated code.