Most automation tools for testing desktop applications break on release day. Here is the four-line function that prevents it.

The maintenance trap is mechanical, not philosophical

Industry surveys put 50% to 70% of QA effort into fixing tests that worked the day before. The vendor pages blame “flaky tests”, a phrase that obscures the actual cause. There is nothing flaky happening at runtime. What is happening is that the tool's identity scheme is too tightly coupled to something the application changes routinely. If the identity scheme is a screen coordinate, a single button-position tweak invalidates it. If it is a screenshot, a theme or DPI change invalidates it. If it is a positional path like Window/Toolbar/Item[3] through the UI tree, reordering two siblings invalidates it.

The fix is not to layer self-healing on top of a fragile scheme. The fix is to start from a scheme that does not depend on the things the app changes for cosmetic and structural reasons.

The four properties Terminator hashes

Every desktop UI element exposed by the OS accessibility tree carries a small set of identity properties. On Windows, those come from the UI Automation (UIA) COM API. Terminator picks four of them, in priority order, and hashes the concatenation:

The function pushes whichever of those four are non-empty into a single string, hashes it with BLAKE3, and returns the first 8 bytes as a u64. If all four are empty (a rare case for anything a real test targets), it falls back to the element's bounding rectangle, and only as a final resort to the in-memory pointer (which is explicitly documented as NOT stable across sessions). The whole function:

// crates/terminator/src/platforms/windows/utils.rs, lines 21 to 88
// Generate a stable element ID based on element properties.
pub fn generate_element_id(
    element: &uiautomation::UIElement,
) -> Result<usize, AutomationError> {
    let automation_id = element.get_automation_id().ok().filter(|s| !s.is_empty());
    let role         = element.get_control_type().ok()
        .filter(|t| *t != ControlType::Custom);
    let name         = element.get_name().ok().filter(|s| !s.is_empty());
    let class_name   = element.get_classname().ok().filter(|s| !s.is_empty());

    let mut to_hash = String::new();
    if let Some(id) = automation_id    { to_hash.push_str(&id); }
    if let Some(r)  = role             { to_hash.push_str(&r.to_string()); }
    if let Some(n)  = name             { to_hash.push_str(&n); }
    if let Some(cn) = class_name       { to_hash.push_str(&cn); }

    if to_hash.is_empty() {
        if let Ok(rect) = element.get_bounding_rectangle() {
            to_hash.push_str(&format!(
                "{}:{}:{}:{}",
                rect.get_left(), rect.get_top(),
                rect.get_width(), rect.get_height(),
            ));
        }
    }

    let hash = blake3::hash(to_hash.as_bytes());
    Ok(hash.as_bytes()[0..8]
        .try_into()
        .map(u64::from_le_bytes)
        .unwrap() as usize)
}

Two things are worth noticing. First, the hash is content-derived, not session-derived; nothing in the input depends on a process ID, a window handle, or a memory address (except the explicit fallback path, which is documented as session-only). Second, BLAKE3 is deterministic for a given input, so equal inputs produce equal hashes regardless of which OS process is running, which CPU is executing it, or how many days have passed since the last run.

The test that fails the build if stability ever regresses

Claims about test stability tend to be marketing prose. This one is a #[tokio::test] in the repository. It is rigged to fail loudly the moment anyone changes the identity scheme in a way that breaks cross-restart stability.

// crates/terminator/src/tests/id_stability_tests.rs
// Verifies that generate_element_id returns the SAME hash after Notepad
// is killed and restarted. If this assertion ever fires, a regression
// has occurred in the identity scheme.
#[tokio::test]
#[ignore]
async fn test_element_id_stability_across_restarts() -> Result<(), AutomationError> {
    let get_notepad_document_hash = || -> Result<usize, AutomationError> {
        let (_guard, desktop, notepad_app) = setup_notepad();
        let document_selector = Selector::Role {
            role: "document".to_string(),
            name: None,
        };
        let doc_element = desktop.engine.find_element(
            &document_selector, Some(&notepad_app), None,
        )?;
        let doc_impl = doc_element
            .as_any()
            .downcast_ref::<WindowsUIElement>()
            .ok_or_else(|| AutomationError::PlatformError(
                "Failed to downcast UIElement".to_string(),
            ))?;
        generate_element_id(&doc_impl.element.0)
    };

    // Launch Notepad, hash the document, kill the process.
    let hash1 = get_notepad_document_hash()?;
    thread::sleep(Duration::from_millis(500));

    // Launch a NEW Notepad instance, hash the document again.
    let hash2 = get_notepad_document_hash()?;

    // Same element across two distinct OS processes -> same ID.
    assert_eq!(
        hash1, hash2,
        "The element ID should be stable when the application is restarted.          If this fails, a regression has occurred."
    );
    Ok(())
}

Two distinct OS processes, two separate UIAutomation interrogations, the same 64-bit ID. That assertion is what lets a test author write role:Button && name:Save today and have it still match the same element on the next CI run, on a fresh Windows VM, after the user's editor has been killed and respawned by the test harness.

How this changes the comparison with the older toolchain

A lot of the desktop test category was shaped before the accessibility tree was a reliable surface to bind tests to. SikuliX targeted images. Older record-and-replay tools targeted coordinates and window handles. Newer entrants layered self-heal on top of those. None of them changed the underlying identity scheme. Terminator did. The practical differences look like this:

The fair caveat: if your target application does not implement the accessibility API at all (some legacy custom-drawn frameworks), all four input properties may be empty, and Terminator falls back to bounding-rectangle hashing, which is more stable than raw pixels but not as stable as a real automation_id. In that scenario, image-based tools and Terminator end up in roughly the same place. Where the accessibility tree is populated (which is the case for almost every modern WinForms, WPF, WinUI, Electron, Qt, and UWP app), Terminator's hash gives you a deterministic identifier that older tools cannot.

What that one mechanism unlocks for a test suite

A stable element ID is unglamorous on its own. The interesting consequences show up in second-order behaviour:

Going from this page to a passing desktop test

The Node.js, Python, and MCP packages currently ship Windows binaries. macOS exists at the Rust layer (cargo add terminator-rs) and Linux uses AT-SPI2. If you want an AI coding assistant to author the suite, point it at terminator-mcp-agent and use the bundled typecheck_workflow tool to validate workflows before running them.

The honest tradeoffs

A page that pretends a tool has no downsides is useless to anyone actually picking one. Here are the places where this approach loses, and why someone might still pick a different tool.

The point of all this

When someone shopping for a desktop testing tool asks “which one is best?”, they are usually about to be handed a list of brand names with feature checkmarks. The checkmarks rarely tell you which tool will still match the same on-screen element after your team ships its next refactor. That property is decided at the layer below all the marketing, specifically at the point where the framework decides what counts as the same element.

Terminator's answer is in utils.rs at line 23, in 67 lines of Rust, and is verified by a tokio test in the same crate. You can read both files in under five minutes. Whatever tool you pick after reading this, ask its docs the same question and read the answer at the same level of detail. If the answer is missing, that is its own answer.