I Built Selenium Self-Healing Tests with AI That Fix Themselves (Here's How)

Published: (December 10, 2025 at 01:33 PM EST)
4 min read
Source: Dev.to

Source: Dev.to

Selenium Self-Healing Demo

The Problem Every QA Automation Engineer Faces

You write a perfect Selenium test on Friday. Monday morning, it fails. The developer changed a button ID from submit-btn to submit-button. Your test is broken, and you’re spending time fixing locators instead of testing new features.

Sound familiar? I’ve been there many times. That’s why I built a framework where AI automatically fixes broken locators—no more maintenance nightmares.

What If Tests Could Heal Themselves?

Traditional Test:
Test runs → Can’t find element → Test fails → You manually fix it

Self‑Healing Test:
Test runs → Can’t find element → AI analyzes page → AI finds new locator → Test continues

The second scenario is now possible, and I’ll show you exactly how to build it.

My Solution: AI‑Powered Self‑Healing

I created a framework that combines:

  • Behavior‑Driven Development (BDD) for readable tests
  • Selenium for browser automation
  • Local AI for intelligent locator fixing

The best part? It runs entirely on your machine using free, open‑source tools.

A Real Example

Gherkin Scenario

Scenario: Search Wikipedia
    Given I navigate to "https://www.wikipedia.org"
    When I search for "Selenium"
    Then the page should contain "Selenium"

Intentional Wrong Locator

private readonly By _searchBox = By.Id("searchBox");  // Wrong!
// The real ID is "searchInput"

When the test runs:

  1. Tries to find element with By.Id("searchBox") → ❌ Fails
  2. AI analyzes the page HTML → finds a suitable locator
  3. Test uses the new locator → ✅ Succeeds

The test heals itself without any human intervention.

How It Actually Works

The Architecture

  1. Layer 1 – The Test (BDD) – Tests are written in Gherkin, a language anyone can read.
  2. Layer 2 – The Self‑Healing Engine – Captures the page HTML when a locator fails and sends it to the AI with context.
  3. Layer 3 – The AI – Runs locally (e.g., Ollama or GPT) and suggests a new locator based on the description provided.

The Code Flow

// Step 1: Normal element finding
try
{
    return driver.FindElement(locator);
}
catch (NoSuchElementException)
{
    // Element not found - activate self‑healing
}

// Step 2: Ask AI for help
var pageHTML = driver.PageSource;
var suggestion = await aiClient.GetSuggestedLocator(
    pageHTML,
    failedLocator,
    "Search box"  // Human description
);

// Step 3: Try AI's suggestion
var element = driver.FindElement(By.XPath(suggestion));
// Success!

The entire process takes about 2–3 seconds.

Why This Approach Works

  • Context‑Aware: AI understands the element description (e.g., “login button”) and finds relevant matches.
  • No Training Required: Uses the model’s general knowledge of HTML; no custom ML training needed.
  • Free and Private: Everything runs locally—no API costs, no data leaves your network (when using Ollama).
  • Language‑Agnostic: Works with React, Angular, Vue, or plain HTML; the AI just reads the rendered HTML.

Setting It Up (Actually Simple)

Step 1 – Install Prerequisites

  • .NET 9 SDK (free)
  • Ollama (free, local AI) or an OpenAI API key
  • Chrome browser

Step 2 – Download the AI Model

ollama pull qwen3-coder:480b-cloud

Step 3 – Run the Demo

dotnet restore
dotnet build
dotnet test

Three commands and you’ll see AI self‑healing in action.

What I Learned Building This

  • AI Needs Context: Providing a description like “search box” is crucial for accurate suggestions.
  • Local AI Is Good Enough: Free models such as Qwen3‑Coder perform excellently for locator fixing.
  • Retry Logic Matters: Implementing multiple retry strategies raised success from ~70 % to ~95 %.
  • Temperature Is Crucial: A low temperature (e.g., 0.1) yields consistent, repeatable locator suggestions.

When Should You Use This?

Good Use Cases

  • Regression suites that break frequently
  • Applications with rapid UI changes
  • Demos where “magic” is impressive
  • Teams with limited QA resources

Not Ideal For

  • Production monitoring (speed concerns)
  • Performance testing (AI adds overhead)
  • Pixel‑perfect element selection requirements
  • Tests that must never produce false positives

The Technical Details

AI Integration

A simple HTTP client talks to Ollama’s API:

var response = await httpClient.PostAsync(
    "http://localhost:11434/api/generate",
    jsonContent
);

Prompt Example

You are a Selenium expert.
This locator failed: By.Id('searchBox')
Element description: Search input box
Here's the HTML: [truncated HTML]
Suggest a new locator that will work.
Return only the locator, nothing else.

Caching Strategy

If the same locator fails on the same page twice, reuse the previous AI suggestion, cutting healing time by ~90 % for repeated failures.

Error Handling

If all AI attempts fail, the test fails normally with a clear error message—no silent failures.

Extending the Framework

  • Add New Sites: Create a new feature file in plain English; self‑healing works automatically.
  • Use Different AI: Switch to OpenAI by updating a single configuration file:
{
  "Provider": "OpenAI",
  "ApiKey": "sk-your-key",
  "Model": "gpt-4o"
}
  • Customize Healing Logic: The engine is extensible; you can add custom strategies for specific element types.

Try It Yourself

The complete framework is available with:

  • Fully commented code
  • Working demo test
  • Setup instructions
  • Documentation

Everything is designed for beginners. Even if you’ve never written a Selenium test, you can get this running in 10 minutes. The repository includes a Wikipedia search test with an intentionally wrong locator to showcase AI fixing it in real time.

GitHub Repo:

Back to Blog

Related posts

Read more »