Test a Legacy App With No Tests Before Refactoring

What Are You Actually Trying to Do Before the Refactor?

Before a refactor, the goal is to prove that the behaviour users rely on is the same afterwards. You have an app that works, mostly, and nobody can say precisely what it does. There are no tests, and the code is the only documentation. You want to change its structure without changing its behaviour.

Much of the advice for this situation is code-level characterisation testing, an approach popularised by Michael Feathers in Working Effectively with Legacy Code and still discussed in Mark Seemann's write-up on empirical characterization testing: read the code, pin down what each function returns today, then refactor. That is sound, but it asks you to understand the code before you have the safety net that would let you change it. A complementary starting point is the behaviour a user can see. If sign-up, checkout and the main workflow still complete after your changes, you have evidence the refactor has not broken the journeys that matter. That fits a view Martin Fowler has long argued: Martin Fowler's article on self-testing code describes automated tests as what lets developers clean up code safely, because a mistake gets caught quickly. A legacy app has no such tests yet, so the first job is to get some form of check in place.

How Does TaloTrace Build Tests for an App Nobody Has Tests For?

You point TaloTrace at your app and, optionally, describe the flow you care about most in plain language, such as "complete a checkout". TaloTrace explores the running app, plans the user journeys worth testing and drives each one to a verifiable outcome. The journeys it completes become replayable scenarios, grouped in a Test Plan.

There are no test scripts to write. If you would rather steer, scenarios can also be authored from a chat description or written by hand.

TaloTrace plans with more than the screen in front of it. It can use product documentation you import, which you can paste directly or pull in from Confluence pages or Linear issues. Re-importing refreshes the existing doc rather than duplicating it. For a legacy app, even a rough internal wiki page can give the planning some context the UI alone does not.

How Does It Get Past the Login?

You save the test accounts TaloTrace should sign in with, once per project, each with a role label such as "admin" or "viewer". Sign-in is email and password, and you can add free-text instructions for logins that need extra steps, such as a one-time code prompt. A scenario can use the project default account, a specific one, or no login at all.

Saved passwords are write-only. They are omitted from every read of the account and masked out of the run's captured steps and logs.

What Does It Do Inside Your App?

TaloTrace commits real actions such as Create, Save and Submit, and reads the resulting screen to confirm what changed. Only destructive or irreversible actions, such as deleting an account or making a payment, are held back. You can also declare boundaries it stays inside. A flow that would cross one is recorded as blocked, with a note on what would be needed to test it safely.

Why Does Proven Completion Matter for a Safety Net?

A safety net that passes when it should not is worse than none. TaloTrace marks a goal done only when a machine-checkable predicate proves the outcome. The predicate must be false before the action and true after it, so a screen that already says "Projects" cannot falsely complete a "create project" goal.

A scan that produces no independently proven goal fails, rather than reporting an unverified journey as a pass. For a team about to rely on these scenarios while changing code, that is the property worth checking first.

How Do You Re-Run the Safety Net as You Refactor?

Scenarios are navigated by looking at the screen, not by brittle element IDs, so they keep working when the UI changes. Their interaction range covers taps, typing, scrolling, swiping, long-press, double-tap, drag and pinch.

Two triggers are available:

• On demand: start a run yourself at any time, from the app or through the API, choosing the scenarios, the build and the device profile.
• On a schedule: set a recurring run, daily or weekly at a wall-clock time in your timezone, optionally tied to a specific Test Plan. A scheduled run is not pinned to a build: it always runs the latest finalized build, so a daily schedule keeps testing whatever you shipped most recently.

Runs happen on cloud-hosted virtual planes: a browser for web apps, an Android emulator for Android apps and an Apple iOS Simulator for iOS apps. There is no hardware to provision. For more on the approach, see how TaloTrace works.

What Do You Get Back From a Run?

Each Run produces a set of Findings. A screen recording is captured for every run, and each finding carries the time window inside that recording where the defect shows, alongside per-scenario verdicts. A vision model also analyses the recording for visual and functional anomalies, not only hard failures. Each finding also comes with TaloTrace's reasoning and step-by-step reproduction, including the Evidence panel showing the step-by-step trajectory.

TaloTrace separates finding a bug from reporting it. It records what looks wrong, then independently verifies each finding before it reaches you. Repeated observations of the same defect collapse into a single issue within a run, and a candidate matching an issue TaloTrace already tracks is routed to that issue instead of surfacing as new.

Severity has five levels, Critical, High, Medium, Low and Trivial, shown with their P-codes such as "Critical (P0)". You can supply your own severity guidance per project, and TaloTrace follows it when rating findings. Findings live in TaloTrace's built-in issue view.

Results start hidden. Findings become visible when a reviewer approves them, or when the project is configured to auto-approve. Low-confidence findings are held separately and are released only by an explicit per-finding decision.

What Makes This Approach Different From Typical Scripted Testing?

Scripted end-to-end suites are written and maintained by people, which is the work a zero-test legacy app has not had. TaloTrace starts from the running app, so the first coverage comes from exploration rather than from authoring.

It has been dogfooded daily on the Growtrics Academy app, and every run's cost is tracked and visible.

Where Does This Safety Net Stop?

Naming the edges is what makes the rest usable, so here they are.

• It is end-to-end, not code-level. TaloTrace tests what the running app does for a user. It will not tell you what an individual function returns, and it does not replace characterisation or unit tests for the code you are about to restructure.
• Coverage depends on what TaloTrace can reach. It completes the journeys it can prove. Flows behind a declared boundary are recorded as blocked, and destructive actions are held back, so those paths need another approach.
• No pull-request trigger. Runs start on demand or on a daily or weekly schedule. Pull-request-triggered runs are not available, and TaloTrace should not be treated as a CI check or merge gate.
• No physical devices. Execution is on the browser, Android emulator and iOS Simulator.
• Device profiles vary. The same scenarios can be run across several device or OS configurations in one submission, but availability of alternate profiles depends on your setup. Ask about device profiles when you book a demo.
• Drawing and signature input is not available. It is in development only, so flows that depend on it should not be assumed covered.

A sensible plan is to let TaloTrace build the first set of journeys, review what it proved and what it blocked, then start refactoring in small steps and re-run between them. If a scenario that completed before no longer does, its per-scenario verdict shows which journey to look at first. For a related look at the Android side, see AI QA testing for Android apps.

How Do You Get Started?

If your refactor is close, the quickest route is to see it against your own app.

Get early access or book a demo