A few weeks ago, my Engineering Manager came to me with a simple ask:

“Can we have a dashboard where I can see how much of our end-to-end test coverage is actually automated?”

Simple question. Not so simple answer.

We had a Cucumber + Playwright test suite running in a Gradle Kotlin project, with feature files neatly sitting inside the repository. But there was no easy way for anyone outside the QE team to see at a glance — “hey, we have 40 features, and 80% of the planned scenarios are covered by automation.”

So I sat down and figured it out. Here’s the full story.

First, we had to decide where to track the scenarios

Before writing a single line of code, I had a conversation with my engineering manager and head of QE about where we’d actually store the E2E scenario data that we’d measure coverage against. We came up with three options.

Option 1: Jira

The idea was to create and maintain E2E scenarios as Jira issues, link them to features or epics, and then use the Jira API to pull counts and calculate coverage. The formula would be straightforward:

Automation Coverage % = (Automated Scenarios / Total Defined Scenarios) × 100

The pros were real. You’d get full traceability from feature to story to scenario to automation. It scales well. It fits nicely into engineering governance.

But the cons were just as real. You’d need to document every single existing scenario in Jira first — a significant upfront effort as we don’t have any test case in Jira. You’d need to manage a Jira API token. And every PR would need to make live API calls to Jira, which adds latency and a hard external dependency to your CI pipeline.

Option 2: A shared Excel/Google Sheet

Keep a spreadsheet with three columns: feature name, scenario name, and status (Automated / Not Automated). A Python script reads it and does the math.

Quick to set up. No tokens needed.

But spreadsheets have a way of rotting quietly. Ownership gets fuzzy. Even though Google Sheets has version history, it’s not very useful for developers. People may forget to update it. After six months it becomes a liability rather than an asset. Not ideal.

Option 3: A CSV file inside the repository

Keep a simple CSV file right inside the E2E test repository. Two columns: feature name and total planned scenario count. A Python script reads it directly during the CI run.

No Jira dependency. No external API calls. No spreadsheet chaos. The data lives right next to the code it describes, so it gets reviewed in the same pull requests.

The trade-off is honest and manageable: the QE team needs to remember to update the CSV whenever they add new features or change scenario counts. That’s it.

We decided to go with option 3

For our team’s situation, this was the right call. We didn’t have Xray or any Jira test management plugin in place, and setting that up just to get a coverage number felt like over-engineering. The CSV approach kept the solution inside our own repository, under version control, with no external dependencies touching our CI pipeline.

The QE team owns the CSV. When they add a new feature file, they add a row to the CSV. Simple contract, easy to enforce in code review.

What I actually built

With the approach decided, here’s what the solution looks like end to end.

The CSV file

A file called planned-automation-tests.csv sits in the repository under the src/test/resources/features directory . It looks like this:

Feature,Planned Automation Test Count
Login,6
Navigation Bar,12
Checkout,8
User Profile,5

The Python script

A script called generate_coverage.py reads the CSV, walks through the actual .feature files in the repository, counts how many scenarios are automated (by counting Scenario: and Scenario Outline: lines), and produces two outputs:

• A Markdown formatted feature coverage summary as a PR comment
• A standalone HTML report for the live dashboard

The Python script will generate a Markdown comment using the template located at scripts/test-coverage-report/templates/test-coverage.md.tpl.

It will also generate an HTML report based on the same template found at scripts/test-coverage-report/templates/test-coverage.md.tpl.

The coverage percentage per feature is simply the automated count divided by the planned count from the CSV.

The coverage report dashboard

This is the part I’m most happy with. The HTML report isn’t just a plain table — it’s a proper interactive dashboard with dark theme styling that I’m hosting for free on GitHub Pages.

At the top of the report, four summary cards give an instant health check at a glance:

• Overall Coverage % — the combined coverage across all features, with a colour-coded progress bar (green when high, amber when moderate, red when low)
• Total Planned — total scenarios defined across all features in the CSV
• Total Automated — total scenarios actually implemented across all feature files
• Total Missing — how many scenarios are planned but not yet automated

These four numbers are the first thing my Engineering Manager looks at. He doesn’t need to scroll a table to understand where we stand.

Search, sort, and filter

The table below the summary cards isn’t static. It has three interactive controls built in.

• Search — a search box at the top lets you type any feature name and the table filters in real time. If you have 30+ features, this saves a lot of scrolling.
• Sort — every column header is clickable and toggles between ascending and descending order. You can sort by feature name alphabetically, by planned count, by automated count, by coverage percentage, or by missing count. The most useful one in practice is sorting by coverage percentage ascending — it immediately surfaces the features with the lowest coverage so the team knows where to focus next.
• Filter by coverage tier — a dropdown above the Coverage % column lets you filter by health status. The three tiers are:
  🟢 ≥ 90% — well covered
  🟡 80–89% — getting there
  🔴 < 80% — needs attention

Each row’s coverage badge is colour-coded to match these tiers, so the table is easy to scan even without using the filter.

The “Missing from CSV” warning

This one saved us from a real problem in the first week.

When a QE engineer adds a new .feature file to the repository but forgets to add a corresponding row to the CSV, the script detects it. It knows the feature file exists (because it can see it in the repo) but has no planned count to measure against.

Instead of silently skipping it or crashing, the report handles it in two ways. First, a warning banner appears at the top of the table.

⚠️ Attention: Some feature files exist but are not included in planned-automation-tests.csv. Please define their planned automation test count to ensure accurate coverage reporting.

Second, the affected row appears in the table with a warning icon (⚠️) and a tooltip “Feature not defined in planned-automation-tests.csv”.

This means the oversight gets caught as soon as the next report generates — either during the PR review or after merge when the dashboard updates. The QE engineer sees it, goes back, adds the CSV row, and raises another PR. It’s a lightweight safety net that keeps the data honest without requiring any manual audit process.

The GitHub Actions pipeline

The CI pipeline is where all of this gets automated. The workflow has four stages, and the design decisions behind each one matter.

Stage 1 — Build

Runs mvn -B clean compile to verify the project compiles. Every PR triggers this regardless of what files changed. This is the baseline check.

Stage 2 — Test

Installs Chrome, runs the full Cucumber test suite using mvn clean test -Pheadless-chrome,qa, and uploads the test report as a build artifact. Again, this runs on every PR — not just ones that touch feature files. You always want your tests to run on every change.

Stage 3 — Report (PR coverage comment)

This stage is smarter. It only does meaningful work when a PR actually changes a .feature file. Here's how that works:

- name: Detect Feature File Changes
  id: changes
  uses: dorny/paths-filter@v3
  with:
    filters: |
      features:
        - 'src/test/resources/features/**/*.feature'

If steps.changes.outputs.features == 'true', the stage runs generate_coverage.py, uploads the HTML as a build artifact, and posts a Markdown coverage summary as a comment directly on the PR. The comment includes a table of all features with their planned, automated, and missing counts, plus a link to the full HTML report artifact.

If no feature files changed in the PR, every coverage step is skipped and a simple “⏭️ No feature file changes detected — skipping coverage report and PR comment.” notice appears in the log. No noise. No redundant comments on PRs that have nothing to do with test coverage.

Stage 4 — Deploy to GitHub pages

The deploy stage only runs on a push to master — meaning a merged PR. It applies the same path filter logic: if no feature files were part of the merge, the entire deploy is skipped. If feature files did change, it regenerates the report fresh from the merged codebase and pushes it to GitHub Pages.

deploy:
  if: github.event_name == 'push' && github.ref == 'refs/heads/master'

A key detail here is that each GitHub Actions job runs on a completely fresh runner. Files generated in one job don’t carry over to another. So the deploy job doesn’t try to download the artifact from the report job — it runs generate_coverage.py again independently. This makes the deploy stage fully self-contained and resilient.

The trigger design

The trigger setup is something I had to think carefully about:

on:
  pull_request:      # ALL PRs trigger build + test
  push:
    branches:
      - master       # Merges to master trigger deploy

There’s no paths filter on the pull_request trigger. I made this mistake initially — I had set it to only trigger when feature files changed, which meant PRs that touched only Java code didn't run any CI at all. Build and test were being skipped silently.

The fix was to let all PRs trigger the workflow, and move the feature file filtering inside the specific jobs that need it. Build and test always run. Coverage reporting only runs when it’s relevant.

A verification step before every deployment

One more thing I added to the deploy stage is a verification step before it tries to copy and publish anything:

- name: Verify coverage report was generated
  run: |
    if [ ! -f artifacts/feature-coverage.html ]; then
      echo "❌ artifacts/feature-coverage.html was not generated. Aborting deploy."
      exit 1
    fi
    echo "✅ feature-coverage.html found ($(wc -c < artifacts/feature-coverage.html) bytes)"

Without this, if generate_coverage.py fails silently or writes to the wrong path, the deploy would still proceed — publishing an empty directory, which GitHub Pages then serves as the repository README. This guard turns that silent failure into a loud, obvious CI error with a clear message.

A few things I learned along the way

• The cache: 'pip' trap:
  When using actions/setup-python with cache: 'pip', GitHub Actions looks for a requirements.txt or pyproject.toml to use as the cache key. If neither exists, the job fails with a confusing error about no matched files. For a single pip install requests, the cache saves maybe two seconds and isn't worth it. Just drop the option.
• GitHub Pages source setting:
  After the deploy workflow successfully pushed to the gh-pages branch, the dashboard was still showing the repository README. The reason was that GitHub Pages was configured to serve from the master branch, not gh-pages. You have to go to Settings → Pages → Branch and change it manually. GitHub doesn't do this automatically even when you start pushing to gh-pages.
• fetch-depth: 0 for path filtering on push events:
  The dorny/paths-filter action diffs the current commit against the previous one to determine which files changed. With the default shallow clone, there's no previous commit to diff against. Adding fetch-depth: 0 to the checkout step gives it the full history it needs.
• force_orphan: true on the Pages deploy:
  Without this, every merge that triggers a deploy adds a new commit to the gh-pages branch. After a few months you'd have hundreds of commits that all just say "update coverage report." Setting force_orphan: true means the branch always has exactly one commit — the latest snapshot. Clean and simple.
• [skip ci] on the deploy commit message:
  The deploy job pushes a commit to the gh-pages branch. Without the [skip ci] tag in the commit message, that push can trigger the CI workflow to run again on itself, creating a loop. Adding it to the commit message tells GitHub Actions to ignore that push.

The Result

My Engineering Manager now has a URL he can bookmark and check anytime. Every time a feature file changes and gets merged, the dashboard updates automatically. No manual reports. No stale spreadsheets. No one needs to remember to do anything.

The PR comment means the QE team gets immediate coverage feedback during code review, right where they’re already looking, without switching tools. The “missing from CSV” warning catches the most common mistake — adding a feature file and forgetting to register it — before it has a chance to silently skew the numbers.

And the whole thing runs on tools we already had: GitHub Actions, Python, and GitHub Pages. Nothing new to pay for or maintain.

It took a few days to get the workflow logic right, but the end result is clean, reliable, and genuinely useful. Sometimes the best dashboards are the ones that just get out of the way and show you what you need.

GitHub Repository

It’s hard to get real value without looking at a concrete implementation and a working example. To make things clearer, I’ve put together a sample repository you can explore and reference.

https://github.com/osandadeshan/cucumber-selenium-java-web-automation-demo

If you’re working with Cucumber and want to set something similar up, the full workflow YAML and Python scripts can be adapted to most Maven or Gradle Java projects with minimal changes. The CSV approach in particular is underrated — it’s boring in the best possible way.

My Engineering Manager asked for a test coverage dashboard. Here’s what I built was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In software development, creating maintainable and scalable code is essential. One way to achieve this is by adhering to SOLID principles. SOLID is an acronym for five design principles that make software designs more understandable, flexible, and maintainable. In this article, I am going to break down each principle with real-world examples using Java.

What is SOLID?

SOLID stands for:

1. Single Responsibility Principle (SRP)
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change. This means that a class should have only one responsibility or job.

Concept: Imagine a class that handles multiple unrelated responsibilities. If a change occurs in one responsibility, it might impact the other responsibilities, making the class harder to maintain.

Detailed Example: Consider a Report class that handles both report generation and formatting:

public class Report {
    private String content;

    public void generateReport() {
        // Logic to generate the report content
        this.content = "Report Content";
    }

    public void formatReport() {
        // Logic to format the report content
        System.out.println("Formatted Report: " + content);
    }
}

Issue: The Report class has two responsibilities: generating content and formatting it. If formatting requirements change, you might need to modify the Report class, impacting both responsibilities.

Solution: Apply SRP by splitting the responsibilities into different classes:

public class Report {
    private String content;

    public void generateContent() {
        // Logic to generate the report content
        this.content = "Report Content";
    }

    public String getContent() {
        return content;
    }
}

public class ReportFormatter {
    public void format(Report report) {
        // Logic to format the report content
        System.out.println("Formatted Report: " + report.getContent());
    }
}

Explanation: Now, Report is only responsible for content generation, while ReportFormatter handles formatting. This makes each class easier to maintain and change independently.

2. Open/Closed Principle (OCP)

Definition: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

Concept: You should be able to add new functionality without altering existing code. This prevents the risk of introducing bugs when modifying existing, stable code.

Detailed Example: Consider a payment processing system that initially supports only credit card payments:

public class PaymentProcessor {
    public void processCreditCardPayment(double amount) {
        // Process credit card payment
    }
}

Issue: If you want to add support for another payment method (e.g., PayPal), you would need to modify the PaymentProcessor class, which could introduce errors.

Solution: Use an interface and separate classes for each payment method:

public interface PaymentMethod {
    void processPayment(double amount);
}

public class CreditCardPayment implements PaymentMethod {
    public void processPayment(double amount) {
        // Process credit card payment
    }
}

public class PayPalPayment implements PaymentMethod {
    public void processPayment(double amount) {
        // Process PayPal payment
    }
}

public class PaymentProcessor {
    private PaymentMethod paymentMethod;

    public PaymentProcessor(PaymentMethod paymentMethod) {
        this.paymentMethod = paymentMethod;
    }

    public void processPayment(double amount) {
        paymentMethod.processPayment(amount);
    }
}

Explanation: PaymentProcessor no longer depends on specific payment methods but rather on the PaymentMethod interface. New payment methods can be added without changing PaymentProcessor.

3. Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types without altering the correctness of the program.

Concept: If a class is a subtype of another, it should be able to replace the parent class without causing issues. This ensures that the derived class adheres to the behavior expected by the base class.

Detailed Example: Consider a base class Bird and a subclass Penguin:

public class Bird {
    public void fly() {
        // Fly implementation
    }
}

public class Penguin extends Bird {
    @Override
    public void fly() {
        // Penguins can't fly
        throw new UnsupportedOperationException("Penguins can't fly");
    }
}

Issue: Penguin violates LSP because it cannot substitute Bird without causing issues.

Solution: Refactor to ensure that subclasses adhere to the expected behavior:

public abstract class Bird {
    public abstract void move();
}

public class Sparrow extends Bird {
    @Override
    public void move() {
        // Flying implementation
    }
}

public class Penguin extends Bird {
    @Override
    public void move() {
        // Walking implementation
    }
}

Explanation: Both Sparrow and Penguin correctly implement move, allowing them to be used interchangeably where Bird is expected.

4. Interface Segregation Principle (ISP)

Definition: A class should not be forced to implement interfaces it does not use. Clients should not depend on methods they do not use.

Concept: Large interfaces that contain methods unrelated to specific clients should be split into smaller, more specific interfaces. This ensures that implementing classes only need to be concerned with methods that are relevant to them.

Detailed Example: Consider a Worker interface with unrelated methods:

public interface Worker {
    void work();
    void eat();
}

Issue: A RobotWorker might not need the eat method:

public class RobotWorker implements Worker {
    public void work() {
        // Robot working logic
    }

    public void eat() {
        // Unnecessary or throws exception
    }
}

Solution: Split the interface into more specific ones:

public interface Workable {
    void work();
}

public interface Eatable {
    void eat();
}

public class HumanWorker implements Workable, Eatable {
    public void work() {
        // Human working logic
    }

    public void eat() {
        // Human eating logic
    }
}

public class RobotWorker implements Workable {
    public void work() {
        // Robot working logic
    }
}

Explanation: Workable and Eatable interfaces are more specific, and RobotWorker implements only the Workable interface, adhering to ISP.

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Concept: High-level modules should rely on interfaces or abstract classes rather than concrete implementations. This reduces the coupling between different parts of the system and enhances flexibility.

Detailed Example: Consider a UserService that directly depends on UserRepository:

public class UserRepository {
    public void save(User user) {
        // Save user logic
    }
}

public class UserService {
    private UserRepository userRepository = new UserRepository();

    public void register(User user) {
        userRepository.save(user);
    }
}

Issue: UserService is tightly coupled with UserRepository, making it hard to change the repository implementation or to test UserService in isolation.

Solution: Use dependency injection and abstractions:

public interface UserRepository {
    void save(User user);
}

public class JdbcUserRepository implements UserRepository {
    public void save(User user) {
        // Save user logic using JDBC
    }
}

public class UserService {
    private UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void register(User user) {
        userRepository.save(user);
    }
}

Explanation: UserService depends on the UserRepository interface rather than a concrete implementation. This allows for different implementations of UserRepository and simplifies testing and maintenance.

Conclusion

SOLID principles needs to be complied when developing software in order to develop code that is reliable and flexible. These SOLID principles Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP) serve as guidelines to ensure that your code remains clean, maintainable, and scalable.

By following SRP, you ensure that each class has a single responsibility, which simplifies maintenance and reduces the risk of unintended side effects when changes are made. The OCP encourages you to design systems that can be extended with new functionality without altering existing code, thereby minimizing the risk of introducing bugs. LSP ensures that derived classes can be used interchangeably with their base classes without breaking the functionality, fostering code reliability and consistency. ISP advocates for creating smaller, more specific interfaces, which makes your code more modular and easier to understand. Finally, DIP promotes the use of abstractions rather than concrete implementations, which enhances flexibility and makes your codebase more adaptable to change.

Incorporating these principles into your Java projects not only helps in building high-quality software but also equips you with best practices that are recognized and valued across the software development industry. By continuously applying SOLID principles, you pave the way for developing software that is easier to test, extend, and maintain ultimately leading to more successful and sustainable software solutions.

Utilize these principles, practice them regularly, and observe how they transform your approach to software design, making your code more robust and adaptable to future changes.

Happy Programming !!!

Quick guide to being solid with SOLID principles in Java was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Unit Testing?

• Unit testing is a testing method that tests an individual unit of software in isolation.
• Unit testing for React Apps means testing an individual React Component.

“Unit testing is a great discipline, which can lead to 40% — 80% reductions in bug density.” — Eric Elliotte

The Test Pyramid

Stick to the pyramid shape to come up with a healthy, fast, and maintainable test suite: Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end. Watch out that you don’t end up with a test ice-cream cone that will be a nightmare to maintain and takes way too long to run.

Benefits of Unit Testing

1. Process becomes Agile

The Agile Testing process is the main advantage of unit testing. When you add more features to the software, it might affect the older designs and you might need to make changes to the old design and code later. This can be expensive and require extra effort. But if you do unit testing, the whole process becomes much faster and easier.

2. Quality of code

Unit testing significantly improves the quality of the code. It helps developers to identify the smallest defects that can be present in the units before they go for the integration testing.

3. Facilitates changes

Refactoring the code or updating the system library becomes much easier when you test each component of the app individually.

4. Smooth debugging

The debugging process is very simplified by doing unit testing. If a certain test fails, then only the latest changes that have been made to the code need to be debugged.

5. Reduction in cost

When bugs are detected at an early stage, through unit testing, they can be fixed at almost no cost as compared to a later stage, let’s say during production, which can be really expensive.

6. Act as the best form of documentation

Unit tests tell you how the original authors intended their code to be used. Read the unit tests and you can learn how the authors consume their own produce.

Best Practices

1. Use one test file per component

Separate different tests into different files to make them well separated, keep the files slim, and make them easily maintainable.

2. Organize your tests with describe and test/it

Use describe to create blocks that group several related tests together and use test or it to execute individual test cases.

3. Setup and reset commons in beforeEach/afterEach hooks

Use beforeEach and afterEach hooks to set up common codes for test cases and reset all mocks after your tests.

4. Use the three A’s pattern

Arrange/Act/Assert (AAA) is a pattern for organizing unit tests. It breaks tests down into three clear and distinct steps:

• Arrange: Perform the setup and initialization required for the test.
• Act: Take action(s) required for the test.
• Assert: Verify the outcome(s) of the test.

5. Also test what should not happen

When writing tests, a common practice is to test what a function should do. But you should not only test the obvious but also test the edge cases and negative cases.

6. Make your tests deterministic

Your tests should not depend on each other. It goes without saying, but for your tests to be deterministic, you want to ensure that your tests don’t depend on each other. Each test case should be independent of the other and should be able to pass on its own.

7. Don’t duplicate implementation logic

You might copy the same flaws in the logic over to your test suite which means your test suite will pass, but not because it is working correctly. Rather, it contains the same bug as your function. Always test the outcomes, not the implementation.

8. Run your tests as part of your deployment

Run your test suite before each deployment to ensure you didn’t accidentally break any functionality. That way, you can ensure that no bugs are released into a test/production environment for parts of your application that are already covered by tests.

Demo Repository

GitHub - osandadeshan/react-jest-unit-testing-demo: A sample project to demonstrate unit testing for a React project using Jest.

References

• https://www.webtips.dev/webtips/jest/jest-best-practices
• https://martinfowler.com/articles/practical-test-pyramid.html
• https://reactjs.org/docs/testing.html

Happy Unit Testing !!!

Unit Testing Best Practices In React was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Healenium?

Healenium is an open-source test framework extension that enhances the stability of Selenium-based test cases. It automatically handles the updated web and mobile elements. In practical scenarios, Web and mobile applications are updated constantly in every sprint and that may cause locator changes. Healenium uses a type of machine-learning algorithm to analyze the current page state for changes, handle NoSuchElement test failures, and fix broken tests at runtime by replacing the failed locator with a new value that matches the best and performs an action with the new element successfully. After the test run, Healenium provides detailed reporting with the fixed locators and screenshots. In addition, it supports advanced features like a parallel test run, remote test run, iFrames, actions, selenide integration.

All of this decreases the time and effort required to write reliable Selenium tests, as well as the number of test cases that fail due to test defects.

How Does It Work?

Healenium has a client component that connects to test automation frameworks. It has a Tree-comparison dependence in it. An algorithm with self-healing capabilities that examines the current DOM state and generates a new CSS locator by searching for the best subsequence in the current state. It also implements Selenium WebDriver and modifies the findElement method, triggering the Tree-comparing process and initiating self-healing if the NoSuchElement exception is caught.

Healenium’s backend is a server that uses a PostgreSQL database to execute interactions between the client and the database, which records old and new locator values as well as relevant information such as DOM page, method name, class name, screenshots, and so on.

There are also Maven and Gradle plugins that generate healing results reports and interact with the backend to obtain information about the healing elements.

Healenium also offers an IntelliJ IDEA plugin for updating the codebase with new location values.

Demo Project

Pre-requisites:

• Clone this GitHub project
  https://github.com/osandadeshan/healenium-demo
• Download and install JetBrains IntelliJ IDEA
• Download and install Docker Desktop

Steps to follow:

Starting the Healenium Backend

1. First, make sure Docker is up and running.

2. Open a Command Prompt or Terminal in the “healenium” directory and execute:

docker-compose up -d

3. Wait for docker to download the images and finish the setup.

4. Using the Docker Desktop UI, check that the Healenium backend and database containers are running.

Or you can execute the below command to check that.

docker ps

Integrating Healenium in tests

It’s as simple as writing one line of code to integrate Healenium into your framework. Wrapping the WebDriver in the new SelfHealingDriver is all that’s required.

But, before that, you have to import,

import com.epam.healenium.SelfHealingDriver;

Example code:

@BeforeMethod
public void before() {
    WebDriver delegate = new ChromeDriver(); // declare delegate
    driver = SelfHealingDriver.create(delegate); // create Self-healing driver
    driver.manage().window().maximize();
    driver.navigate().to("http://automationpractice.com/");
}

Running the tests

Run the tests with the proper locators at least once using mvn clean test. After that, we make the following changes to “index.html” in the “src/main/resources/checkout” folder. (You can change any locators as you wish)

• id=“address” to id=“address1”
• id=“cc-name” to id=“card-name”
• id=“cc-number” to id=“card-number”
• id=“cc-expiration” to id=“card-expiration”
• id=“cc-cvv” to id=“card-cvv”
• “Continue to checkout” to “Checkout”

Normally, this would cause the locators to malfunction because they rely on exact matches. The test will pass because the self-healing driver is used, and it will heal the locators during the runtime.

The locator has been fixed, and the action has been appropriately done, as indicated by the red boxes.

Let’s say you want to fine-tune Healenium to include a score cap or recovery tries. In such a scenario, create a file called “healenium.properties” and place it in the test resources (“src/test/resources”) directory. The following is the file’s content:

recovery-tries = 1
score-cap = 0.5
heal-enabled = true
serverHost = localhost
serverPort = 7878

• recovery-tries — The number of times the algorithm will try to discover a matched locator.
• score-cap — The minimum matching score required for the detected locator to be accepted (50% is represented by the number 0.5).
• heal-enabled — A toggle switch that turns healing on or off. True and false are the accepted values.
• serverHost — The URL of the Docker Container server that we established while setting up the backend.
• serverPort — The above-mentioned server’s port

Run the tests using mvn clean test to generate a new report from the command line. A link to the report generated in the console will appear after a successful test run.

When you open the link in a browser, you’ll get a list of all the locators that have been fixed, along with screenshots of the page where the locators have been fixed. On the right side, there’s a switch to see if the locator has been properly resolved with the correct one.

This boilerplate also includes an Allure report as an added feature. After running mvn clean test, run allure serve target/allure-results to generate the Allure report.

By installing the “Healenium” IDE plugin, you can enable the automatic locator updating feature into the IntelliJ IDEA. You can right-click on the locators you want to correct and select Healing Results. You’ll see a little window with a list of fixed locators to choose from, along with their corresponding scores.

Happy Automation !!!

No more test flakiness from Selenium locator changes was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

What is a Code Review?

“Code Review, also known as Peer Code Review, is the act of consciously and systematically convening with one’s fellow programmers to check each other’s code for mistakes and has been repeatedly shown to accelerate and streamline the process of software development like few other practices can.” (From SmartBear).

The Benefits of Code Reviews

• Improves code quality: Code reviews improve code quality by detecting issues before they snowball out of control and ensuring consistent standards. This leads to robust software that is built from components for seamless integration and functionality.
• Supports knowledge transfer: Source code that is constantly under review allows developers to learn more reliable techniques and best practices.
• Helps teams create better documentation: Code reviews also help teams to create better documentation, which makes it easier for developers to add features and upgrade existing ones in the future.
• Makes QA testing easier: Another benefit of maintaining consistent standards is a source code that is easier for specialists and testers to understand. In Quality Assurance (QA) testing, testers will not only have to check the quality of the code, but they will also have to identify issues leading to poor tests. This can lead to persistent, avoidable delays in development due to further testing and reworking.

Challenges in Code Reviews

• Code review happens too late in the development process: The work has already been done. To rework or to start again could be very time-consuming. The reviewers have a difficult choice: risk the current release while the work is redone, or let it through and suffer the additional technical debt.
• The Wait Time: This is the biggest issue in code reviews. When the author of the code opens a pull request and marks it ready for review, they need to wait until another person comes along and reviews it. This could be 1 hour after the pull request has been opened (if you are lucky) or it might take a few days or even weeks (if you are not lucky). The wait time is especially painful for us programmers because, after each wait time, the context is lost and needs to be rebuilt again. The longer the wait time the more difficult it is to remember how all the code changes fit together into the shippable feature.

Solution for the challenges in Code Reviews

• Automated code reviews: It will provide quick feedback for the commits you pushed to the repository.

How to integrate automated code reviews into your project?

Required Tool

• Code Inspector GitHub Action

How does it work?

Steps to follow

Step 1: Create a project in Code Inspector

• Sign up on Code Inspector.
• Create a project.
• Install Code Inspector for a repository or multiple repositories you like to have automated code reviews.

Step 2: Get your Code Inspector API keys

• In your profile, generate API keys.

• Once you click on the button, the following window will appear.

Step 3: Configure your Code Inspector API keys in your GitHub repository

• You need to add your Code Inspector API keys into GitHub.
• On GitHub, go in your repository settings, click on the secret Secrets (on the right), and create a new secret.
• Create a secret called CODE_INSPECTOR_ACCESS_KEY and set it to the value of the access key generated at the previous step.

• Create another secret called CODE_INSPECTOR_SECRET_KEY and set it to the value of the secret key generated at the previous step.

• Once all secrets have been created, we should have the following secrets generated.

Step 4: Configure the GitHub action

Create a file .github/workflows/main.yml and insert the following content.

The following parameters should NOT be changed:

• repo_token: This is how Code Inspector can access your repository
• code_inspector_access_key and code_inspector_access_key: This is how the action can communicate with the Code Inspector analysis engine.

The following parameters CAN be changed:

• min_quality_grade: The minimum grade your project should have. Valid values are: EXCELLENT, GOOD, NEUTRAL, WARNING, CRITICAL
• min_quality_score: The minimum code quality scores your project should have. This is a value between 0 and 100.
• max_defects_rate: The number of defects per line of code. For example, the value 0.001 means 1 defect per 1000 lines of code.
• max_complex_functions_rate: The rate of complex functions (E.g. functions with high cyclomatic complexity). For example, a value of 0.5 means that the code should not have more than 50% of functions with high complexity.
• max_long_functions_rate: The rate of long functions (E.g. functions that are too long to be correctly read by developers). For example, a value of 0.4 means that the code should not have more than 40% of long functions.
• project_name: The name of the project on Code Inspector. This argument is optional: if you set a project name, the analysis engine will use the preferences of this project. Leave blank for not using a project.
• max_timeout_sec: How many seconds the analysis should come back to you. Default is 600 secconds (10 minutes).

Step 5: Enjoy the automated code reviews

• Push a new commit and the Code Inspector engine will check if the new code meets your criteria.

• To visualize the details of the result, you can use the frontend, command-line client, or use directly API.
• Code Inspector’s frontend dashboard for the project.

• Code Inspector’s frontend analysis for the project.

• Once we click on the “Violations” showing on a red color chip, we can see the violations on the code.

Demo Project

GitHub Repo: https://github.com/osandadeshan/code-quality-demo

Setting up Automated Code Reviews was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is a Boilerplate?

In computer programming, boilerplate code or just boilerplate are sections of code that are repeated in multiple places with little to no variation. When using languages that are considered verbose, the programmer must write a lot of code to accomplish only minor functionality. Such code is called boilerplate.

The need for boilerplate can be reduced through high-level mechanisms such as metaprogramming (which has the computer automatically write the needed boilerplate code or insert it at compile time), convention over configuration (which provides good default values, reducing the need to specify program details in every project) and model-driven engineering (which uses models and model-to-code generators, eliminating the need for manual boilerplate code).

Web UI Automation Boilerplates

Mobile Automation Boilerplates

API Automation Boilerplates

Reporting Boilerplates

Happy Automation !!!

Boilerplate projects for Junior Automation Engineers was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Java plugin for TestNG to analyze the failed and skipped tests easily in test automation.

Introduction

The main reason for developing this plugin is to provide an easy way to analyze the failed and skipped tests in test automation.

MaxSoft TestNG Test Results Analyzer comes with a built-in failed and skipped tests grouping mechanism. It will generate an Excel file with the failed and skipped tests against the reason. On the same Excel file, the second and third tabs contain the failure and skipped tests grouped under the reason. So it would be easy to identify the tests which failed or skipped due to the same reason.

Further, this library has built-in Extent reporter as well. So, no need to worry about the HTML report generation for test executions.

Features

Test Analysis Report Features

1. Test Summary

2. Failure Analysis

3. Skipped Analysis

Extent Report Features

1. Dashboard View

2. Tests View

3. Category View

4. Exception View

Advantages

• Automatically generates the Test Analysis Report after the test execution.
• Automatically generates the Extent Report with screenshots after the test execution.
• Reporter details can be configured through a property file.
• No need to implement classes for Extent reporter or Test Analysis reporter.
• Simple and easy to use.

Technologies/Frameworks Used

• Java
• TestNG
• Apache POI
• Extent Report
• Selenium
• Apache Maven

Supported Platforms

• Windows
• Linux
• Mac OS

Supported Language

• Java

Supported Test Runner

• TestNG

How to use

Pre-Requisites:

1. Java
2. Maven

Steps:

1. Add “MaxSoft TestNG Test Results Analyzer” dependency into “pom.xml”.

2. Create “test-results-analyzer.properties” in “src/main/resources”.

3. In the test automation code, find the place you are launching the WebDriver.

4. Pass your WebDriver object to the “setDriver()” method which can be imported from “import static com.maxsoft.testngtestresultsanalyzer.DriverHolder.setDriver”.

5. Update the places where your are using WebDriver object, into “getDriver()” method which can be imported from “import static com.maxsoft.testngtestresultsanalyzer.DriverHolder.getDriver”.

6. An example test. class.

7. Create the “testng.xml” by adding the “com.maxsoft.testngtestresultsanalyzer.TestAnalyzeReportListener” listener class.

8. Run the “testng.xml”.

Happy Automation !!!

MaxSoft — TestNG Test Results Analyzer was originally published in MaxSoft — TestNG Test Results Analyzer on Medium, where people are continuing the conversation by highlighting and responding to this story.

“The best leaders are the best learners. You have to believe that you (and others) can learn to lead, and that you can become a better leader tomorrow than you are today. Leaders are constant improvement fanatics, and learning is the master skill of leadership.” – Jim Kouzes, Co-author of The Leadership Challenge and The Student Leadership Challenge

If you think about an good organization, everyone regardless of their titles or positions is encouraged to act like a leader.

Here, I am explaining about The Five Practices of Exemplary Leadership to improve your leadership skills.

1. Model the Way

• Leaders should establish how the team members should be recognized or treated and goals pursued.
• Leaders should be examples for the team members.
• If you think that some task cannot be completed within a given period of time, then you should not give that task to a team member. If you did that, it would be a bad model for the team members and your image will be bad for them.

Important points for modeling the way

1. Titles are granted, but your behavior earns you respect.
2. Words and deeds must be consistent.
3. You must affirm the shared values of the group.

2. Inspire a Shared Vision

Leaders envision the future, see what the organization can become, and get others to see those possibilities.

Important points for modeling the way

1. You have to inspire commitment, not command it.
2. Visions seen only by leaders are insufficient to create change in a company.

3. Challenge the Process

Look for innovative ways to improve organizations and accept disappointments as learning opportunities.

Important points for modeling the way

1. Leaders venture out; they don’t sit idly by.
2. Create a climate where good ideas are supported.

4. Enable Others to Act

Leaders foster collaboration and build spirited teams by actively involving others.

Important points for modeling the way

1. Giving power to mentees grants them ownership, making them more capable.
2. Seeking opinions of others builds up their capabilities.

5. Encourage the Heart

To keep hope and determination alive, leaders recognize contributions that individuals make.

Important points for modeling the way

1. Create a culture of celebrating values and victories.
2. Celebrations and rituals can carry a group through tough times.

“A leader is a dealer in hope.”
Napoleon Bonaparte

How to Be a Leader Everyone Loves to Work With was originally published in Test Automation Master on Medium, where people are continuing the conversation by highlighting and responding to this story.