Keep end-to-end tests useful as your app changes

You change a screen, and a browser test breaks. Now somebody has to work out whether the change broke the product or only the test, repair whatever needs repairing, and run it again.

That investigation is part of the cost of owning an end-to-end test. The original script may have been quick to write. Keeping it useful means remembering what the user was trying to accomplish and checking that each repair still tests that job.

I use Jevitate because I want to spend less effort reconstructing browser workflows and more effort deciding whether they work. A reviewed Journey gives me a path I can replay, repair within limits, and reuse to investigate what happens when a user goes off that path.

One order flow gives the test a purpose

Take the small order wizard in Jevitate’s browser-test fixtures. A person enters a name, moves to a review screen, and confirms. There are no real orders or payments in this example.

The job is easy to describe: review and submit an order for the intended person. The test follows that flow and checks the completion element at the end.

That is a starting point for review. Does the flow match what the user needs? Could the test pass even though the wrong person’s order was submitted? In a real application, what would show that the order was stored correctly?

These questions belong with the test. A path through the interface can stay executable long after it stops checking the behavior you care about.

Jevitate can discover a path from a goal and success check, then save it as an unpromoted Journey. You inspect what it found before adopting it. That gives you a concrete flow to review instead of having to specify every browser interaction up front.

A changed button still needs a decision

Suppose the wizard’s Next button becomes Continue. The user may still be able to finish the order, but the recorded click no longer matches.

The immediate task is to check whether the new button performs the same job. If it does, update the Journey. If the flow now skips review or submits something different, the failed test has exposed a product change that deserves a closer look.

Jevitate’s self-healing has a narrower role than automatically accepting either outcome. When explicitly enabled, it can attempt to relearn an eligible read-only step while checking the expected result and preserving the rest of the flow. A recovered run is marked as healed so you can inspect it.

The changed button in this example is a click step, so it falls outside that automatic repair allowance. Clicks, fills, and other write steps still require intervention. A healed recording also needs review before you retain it as the saved Journey.

The aim is to reduce eligible repair work while keeping the decision about intended behavior with the people responsible for the product.

Reuse the review screen to look for other failures

Once the normal order flow works, there are more questions to ask. What happens if someone confirms twice? What happens if they go back, change the name, and return to review?

Reaching that screen is part of the test setup. In this wizard, the review screen is built from the name entered earlier. Opening its URL in a new browser session would lose that state.

Jevitate can replay the Journey to the review point, then start an adversarial mission in the same browser context. Its fixture test checks that the mission sees “Confirm order for Alice” without loading the wizard again. The flow has done the setup work, and the investigation starts where the question matters.

That is the benefit I want from maintaining a Journey: I can reuse the route into the application for more than a single happy-path check. Exploratory missions can investigate from there too, and a sweep can visit several points along the flow.

The branching machinery does not decide what counts as correct order handling. For a real double-submit test, someone still needs to define and check whether duplicate orders were created. Suggested probes help direct the investigation; evidence has to support the finding.

Keep a broken starting point visible

If the Journey can no longer reach Review, Jevitate stops that anchored investigation as inconclusive. It does not start again from the URL and treat that as the same state. The replay used to reach a branch point does not self-heal.

This keeps the maintenance task visible. Before interpreting the adversarial result, inspect the changed path and establish that the investigation can still reach the state it was meant to test.

People continue to own the goal, success checks, permissions, and test data. They also review changes to the saved Journey. In the implementation examined here, promotion is not automatically invalidated by every file edit, so repository review remains part of that responsibility.

A Journey can take on browser checks you would otherwise maintain as scripts, while also providing setup for exploratory and adversarial testing. Whether that saves your team time depends on the flows you test and the changes they undergo. Unit and integration tests still belong where they can check behavior more directly.

Pick one browser test that repeatedly needs repair. Review the user’s job and its success condition, then use the same Journey to reach a state worth investigating. Track the work you still have to do by hand before deciding how much more of the suite to move over.

Technical scope and implementation sources

This article describes source revision 73d164896cfc4faf001ca437bef3bf91cc317fa3, examined October 16, 2026. Self-healing is opt-in and returns a repair rather than automatically saving it. Anchored exploration checks promotion; the direct CLI replay path does not contain the same explicit check. Annotation approval has a separate content-hash guard and does not approve actions or assertions. Check the behavior of your installed version before relying on those boundaries.