DEV Community: krishnamurthy yarram

Stop Using Thread.sleep(): Smart Polling for CloudWatch Log Validation in Java (AWS Test Automation)

krishnamurthy yarram — Wed, 25 Feb 2026 06:27:21 +0000

While building automation frameworks for distributed systems, I ran into a common but frustrating issue:

Our tests would trigger an API, but the logs in AWS CloudWatch would appear 2–4 minutes later.

The result?

❌ Tests failing even though the system was working perfectly.

At first, the “quick fix” seemed obvious:

Thread.sleep(240000);

But that’s one of the worst things we can do in automation.

Here’s how I solved it properly using a smart polling mechanism in Java.

🚨 The Problem: Asynchronous Systems

Modern systems are asynchronous.

API triggers background processing
Services communicate via queues
Logs appear with delay
Eventual consistency is normal

If your test validates logs immediately after triggering an API, it will often fail.

Not because the system is broken.

But because your test is impatient.

❌ The Wrong Approach

Using fixed waits:

Thread.sleep(240000); // Wait 4 minutes

Why this is bad:

Slows down your entire suite
Wastes CI/CD time
Still fails if logs take 5 minutes
Makes tests flaky
Hides real timing behavior

Fixed waits are blind waits.

We need intelligent waits.

✅ The Right Approach: Smart Polling

Instead of waiting blindly:

Execute CloudWatch Insights query
Check query status
Verify results are not empty
Retry until timeout
Fail gracefully if condition never met

This approach:

Waits only as long as needed
Stops early if logs appear
Avoids unnecessary delays
Makes automation resilient

🏗 Architecture Overview

Test

↓

Trigger API

↓

Execute CloudWatch Query

↓

Polling Utility

↓

Wait Until Condition Met

↓

Assert Logs

🧠 Implementing Smart Polling in Java

Here’s a clean polling utility method:

public void waitUntil(BooleanSupplier condition, 
                      int timeoutSeconds, 
                      int pollIntervalSeconds) {

    long endTime = System.currentTimeMillis() + timeoutSeconds * 1000L;

    while (System.currentTimeMillis() < endTime) {

        if (condition.getAsBoolean()) {
            return;
        }

        try {
            Thread.sleep(pollIntervalSeconds * 1000L);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    throw new RuntimeException("Condition not met within timeout.");
}

🔍 Using It for CloudWatch Log Validation

Example usage:

waitUntil(() -> {

    QueryResult result = cloudWatchClient.executeQuery("your query here");

    return result.getStatus().equals("Complete") &&
           !result.getLogs().isEmpty();

}, 300, 10);

This means:

Wait up to 300 seconds (5 minutes)
Poll every 10 seconds
Exit early if logs are found

Much smarter than sleeping blindly.

💡 Why This Matters in Real Projects

In microservices architecture:

Logs are delayed
Events are processed asynchronously
Systems rely on eventual consistency

Your automation framework must understand that.

Otherwise, you’ll end up debugging “failures” that are not actually failures.

🔥 Advanced Improvements

To make this production-grade:

1️⃣ Add Logging

Log every polling attempt for transparency.

2️⃣ Make Timeout Configurable

Read timeout values from config files or environment variables.

3️⃣ Add Exponential Backoff

Instead of fixed intervals:

Start with 5 seconds
Increase gradually
Reduce load on AWS APIs

4️⃣ Combine With Assertions

Validate log content once logs appear.

📊 Benefits of Smart Polling

Faster execution (no unnecessary waiting)
More reliable CI/CD pipelines
Reduced flakiness
Better system-awareness
Cleaner framework design

⚠️ Important Principle

Good automation frameworks are not just about UI clicks.

They must understand distributed system behavior.

If your system is asynchronous,
your tests must be asynchronous-aware.

🎯 Final Thoughts

Thread.sleep() is easy.

But it’s rarely correct.

Smart polling makes your automation:

Faster
Cleaner
More professional
More production-ready

If you're validating CloudWatch logs or any asynchronous behavior, stop sleeping blindly and start polling intelligently.

Building a Self-Healing XPath Mechanism in Selenium (Java) – Stop Fixing Broken Tests

krishnamurthy yarram — Wed, 25 Feb 2026 06:14:15 +0000

Building a Self-Healing XPath Mechanism in Selenium (Java)

If you’ve worked with Selenium long enough, you’ve experienced this:

✅ Tests passing yesterday
❌ Same tests failing today
🤯 Reason? Broken XPath

Modern UI frameworks like React, Angular, and Vue constantly change:

Dynamic IDs
Auto-generated attributes
DOM structure updates
Component re-rendering

As automation engineers, we often spend more time fixing locators than building test logic.

So I asked myself:

Can we build a mechanism that automatically heals broken XPaths instead of failing immediately?

This blog walks through how I designed a basic self-healing locator mechanism using Java + Selenium.

💡 The Core Idea

Instead of directly calling:

driver.findElement(By.xpath("//button[@id='loginBtn']"));

We create a smart wrapper:

smartFindElement("//button[@id='loginBtn']");

If the primary XPath fails:

Attempt fallback search
Scan DOM for similar elements
Compare attributes
Score possible matches
Return the best candidate
(Optional) Update locator storage

🏗 Architecture Design

Test Layer

↓

Smart Locator Manager

↓

Primary XPath Attempt

↓ (if fails)

Healing Engine

↓

Attribute Scoring

↓

Return Healed Element

🧠 Step 1: Smart Find Method

public WebElement smartFindElement(String xpath) {
    try {
        return driver.findElement(By.xpath(xpath));
    } catch (NoSuchElementException e) {
        System.out.println("Primary XPath failed. Attempting healing...");
        return healElement(xpath);
    }
}

🧠 Step 2: Healing Logic

private WebElement healElement(String oldXpath) {

    List<WebElement> candidates = driver.findElements(By.xpath("//*"));

    WebElement bestMatch = null;
    int highestScore = 0;

    for (WebElement element : candidates) {
        int score = calculateScore(element);

        if (score > highestScore) {
            highestScore = score;
            bestMatch = element;
        }
    }

    if (bestMatch == null) {
        throw new NoSuchElementException("Element not found even after healing.");
    }

    System.out.println("Healed element found with score: " + highestScore);
    return bestMatch;
}

🧠 Step 3: Attribute Scoring Strategy

We assign weights to stable attributes:

Attribute	Weight
id	5
name	4
text	3
class	2

Example implementation:

private int calculateScore(WebElement element) {
    int score = 0;

    if (element.getAttribute("id") != null)
        score += 5;

    if (element.getAttribute("name") != null)
        score += 4;

    if (element.getText() != null && !element.getText().isEmpty())
        score += 3;

    if (element.getAttribute("class") != null)
        score += 2;

    return score;
}

🔥 Advanced Improvements (Hackathon-Level Ideas)

1️⃣ Store Historical Locator Mapping

When healing succeeds:

Store:

Old XPath → New Working XPath

Options:

JSON file
Database
Cloud storage
CI logs

2️⃣ DOM Similarity Comparison

Instead of simple scoring, compare:

Tag name match
Parent structure similarity
Sibling index
Levenshtein distance for attribute values

3️⃣ AI-Based Healing

Train a lightweight ML model to:

Predict stable attributes
Learn from past locator failures
Identify patterns in dynamic IDs

✅ Benefits

Reduced maintenance effort
Faster CI/CD execution
Fewer flaky tests
More resilient automation framework

⚠️ Challenges

Performance impact if scanning entire DOM
Risk of incorrect healing
Requires strong logging
Must avoid masking real UI bugs

🎯 Final Thoughts

Self-healing locators are not magic.

But when implemented carefully, they can drastically reduce maintenance overhead and make automation frameworks smarter.

Instead of reacting to broken tests, we can build systems that adapt.

If you're working on Selenium + Java frameworks, this is a great hackathon idea or framework enhancement project.