March 25th, 2026 by Adam Sandman
ai inflectraai automated testing
One of the most compelling things about Rapise 9.0 is that its new self-healing capability is not just a theoretical AI feature. It solves a very real automation problem: what happens when the application under test changes so much that a previously recorded test should, by all traditional standards, break. To illustrate that, we took our sample Library Information System, recorded a test using the original ASP.NET version, then tried the same recorded test against the newer React-based version and relied on the new self-healing functionality to adjust the test without any human intervention. The results were astounding!
The test scenario
The scenario itself was intentionally simple: record a test that creates a new book in the original ASP.NET application, then see what happens when that exact same test is executed against the React implementation. Normally, this kind of migration is exactly where UI automation becomes fragile. Even when the business flow is identical, the underlying application structure is often completely different:
- Control hierarchies change
- HTML changes
- IDs and classes change
- and the object repository that worked perfectly in the first version no longer maps cleanly to the second.
That is the maintenance burden Rapise 9.0 is designed to reduce. This version introduces SmartActions as a self-healing layer that combines object descriptions with action intent expressed in natural language, then uses AI-based visual recognition and contextual analysis when the web locators fail.
This recovery process is multi-level:
- Rapise first tries standard repository lookup
- then AI-based recovery, and finally deeper intelligent resolution
- after which it can generate patch files to update the repository for future runs.
Why this example matters
This is a useful example because the move from the ASP.NET version to the React version is not just a minor cosmetic update. It represents a front-end technology shift. From an automation perspective, that is usually where recorded tests become expensive to maintain. The user journey may still be “log in, go to books, add a new book, save,” but the UI implementation underneath can be radically different.
For example, the application shown above, looks completely different when it was modernized to React:
In older test automation models, that would usually mean going back into the test, relearning objects, editing locators, and repairing the repository by hand. In Rapise 9.0, the self-healing flow changes that experience. Because the recorded actions carry descriptive intent, the test has more context about what it is actually trying to do, not just which technical object it originally found.
For example, the login button has the following intent:
What happened during playback
When the recorded ASP.NET test was played back against the React version, Rapise was able to continue execution using self-healing. That is the important point. The test was not tied so rigidly to the original implementation that it simply failed at the first UI mismatch. Instead, Rapise used the SmartActions approach to interpret the action, inspect the changed interface, locate the equivalent elements in the React UI, and continue the scenario.
From an end-user perspective, this is where the feature becomes much easier to understand. Self-healing is not magic and it is not random guesswork. Rapise still begins with the normal learned objects and repository references. But when those no longer line up with the current application, it has another layer to fall back on. That fallback uses visual and contextual analysis to identify the correct element when the UI has changed.
In practical terms, that means a test step such as creating a book is no longer understood only as “click this exact stored object.” It can also be understood as “perform this action on the control that now corresponds to the original intent.”. That is what allows Rapise to adjust dynamically to changes in the UI - it knows what was the original intent of the user.
From healing to permanent maintenance reduction
The second half of the story is just as important as the first. After Rapise successfully played the test using self-healing, I was then able to apply the detected changes. Once those updates were accepted, the test could play back against the React application again without needing AI recovery. The updates are presented to the user in a simple to understand format where you can Approve or Reject them either individually or in bulk:
That is a critical part of the value proposition. Self-healing is not only about rescuing one execution. It is also about shortening the path back to stable deterministic automation. When SmartActions successfully recovers an object, Rapise can generate patch files that update the repository so future runs benefit from the healing without repeated AI intervention. A sample patch file is shows above.
For teams maintaining large automation suites, that is exactly the difference between a helpful demo and a genuinely useful feature. If AI only helps during one run but leaves the suite in a permanently fuzzy state, maintenance is still a problem. But if AI helps bridge the change, surfaces the updates, and lets the team convert those discoveries into an updated repository, then the test suite becomes stable again on the new UI.
Why this is different from traditional self-healing claims
A lot of test automation tools talk about self-healing, but many of those approaches are still heavily locator-centric. They may retry similar attributes or search for nearby DOM patterns, but they remain narrowly tied to the original technical structure. Rapise 9.0 takes a broader approach by combining object information with natural language action intent and AI-based visual recognition. That means it is not just asking, “What selector is close to the old selector?” It is also asking, “What is this step trying to accomplish on the screen?”
That distinction matters more as teams modernize applications. When organizations move from legacy web stacks to newer front-end frameworks, they often want to preserve their regression coverage without rebuilding every test from scratch. The ASP.NET-to-React Library Information System example shows how Rapise can help make that transition more manageable.
A better model for UI automation maintenance
What this example ultimately demonstrates is a better maintenance model for UI automation. First, record and run the test in the normal way. Second, when the UI evolves, let Rapise use self-healing to identify the equivalent controls in the updated application. Third, review and apply the resulting changes so the repository reflects the new implementation. Finally, return to normal playback without ongoing AI dependency. For example, in our application, the original playback took about 15 seconds, playback with AI took about 2 minutes, and after self-healing, the tests went back to taking about 15-20 seconds again:
That workflow is important because it keeps AI in the right role. It is there to help teams adapt to change, not to replace test engineering discipline altogether. In the Library Information System example, the AI layer provided the bridge between two materially different implementations of the same workflow. Once the changes were accepted, the test became stable again on the new version.
Why this self-healing is different?
The jump from the ASP.NET Library Information System to the React version is a strong illustration of what Rapise 9.0 self-healing is really for. It is not just about recovering from a renamed button or a moved field. It is about preserving the value of your test assets when the application underneath them evolves. By combining stored object knowledge, natural language action descriptions, AI-driven visual recovery, and repository patching, Rapise gives teams a practical way to carry automated tests forward through UI change instead of repeatedly starting over. The result is less manual maintenance, faster adaptation to redesigned applications, and a clearer path from AI-assisted recovery back to stable automated playback.
As companies start to use agentic AI development tools like Claude Code or Amazon Kiro, the rate of change of the underlying application is only going to increase, making this problem even more important to solve than before!
