Reporting and CI Integration

Required tools

• JDK (21 LTS or newer)
• Apache Maven (3.9+)
• Selenium WebDriver (4.x)
• A terminal (any)

Setup

1. Continue from the selenium-learning-lab project used in this course's earlier guided local labs.
2. Add a page-object package and a JUnit extension class for automatic failure screenshots.

Project structure

selenium-learning-lab/
  pom.xml
  src/
    main/java/com/visaspark/selenium/pages/
      SearchPage.java
    test/java/com/visaspark/selenium/
      ScreenshotOnFailureExtension.java
      RefactoredWorkflowTest.java

Starter files

package com.visaspark.selenium;

import org.junit.jupiter.api.extension.ExtensionContext;
import org.junit.jupiter.api.extension.TestWatcher;
import org.openqa.selenium.*;
import java.io.File;
import java.nio.file.*;

public class ScreenshotOnFailureExtension implements TestWatcher {
    @Override
    public void testFailed(ExtensionContext context, Throwable cause) {
        // TODO: retrieve the WebDriver instance for this test (e.g. from a static field
        // or the test instance itself), call getScreenshotAs, and copy it to a real file
        // named using context.getDisplayName()
    }
}

package com.visaspark.selenium;

import org.junit.jupiter.api.*;
import org.junit.jupiter.api.extension.ExtendWith;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

@ExtendWith(ScreenshotOnFailureExtension.class)
class RefactoredWorkflowTest {
    static WebDriver driver;

    @BeforeEach
    void setup() {
        ChromeOptions options = new ChromeOptions();
        // TODO: add "--headless=new" when running in CI (check an env var like CI)
        driver = new ChromeDriver(options);
    }

    @AfterEach
    void teardown() {
        driver.quit();
    }

    @Test
    void refactoredWorkflowUsesPageObjects() {
        // TODO: use a page object (create one under src/main/java) instead of raw
        // findElement calls directly in this test method
    }
}

Requirements

• At least one page object class exists under src/main/java, used by the test instead of raw findElement calls.
• ScreenshotOnFailureExtension genuinely captures and saves a screenshot when a test fails.
• ChromeOptions conditionally adds '--headless=new' based on an environment variable (e.g. CI), matching the CI-vs-local branching pattern.
• `mvn test` produces a Surefire XML report under target/surefire-reports/.

Commands to run

• Run the suite locally (headed, visible browser)

  mvn test

• Run the suite as CI would (headless)

  CI=true mvn test

• Inspect the Surefire report

  cat target/surefire-reports/*.xml

Expected behavior

The refactored test passes identically in both headed and headless (CI=true) modes, using a page object rather than raw locator calls directly in the test. Deliberately breaking the test (temporarily) produces a real screenshot file via the extension. A Surefire XML report exists after every run.

Verify it yourself

• mvn test

  Expected: BUILD SUCCESS; a real, visible Chrome window is observed

• CI=true mvn test

  Expected: BUILD SUCCESS; no visible browser window appears, but the test still passes identically

• ls target/surefire-reports/

  Expected: At least one .xml report file exists

• (temporarily break the test's assertion) mvn test

  Expected: The test fails, AND a real failure-*.png screenshot file is created by the extension

Troubleshooting

• Headless mode fails but headed mode passes — This is a real signal worth investigating, not dismissing — check for code that accidentally depends on window focus or a rendering-timing-sensitive race condition, rather than assuming headless mode itself is broken.
• ScreenshotOnFailureExtension doesn't produce a file — Confirm the extension can actually access the same WebDriver instance the failing test used — a common approach is a static field or a JUnit store, since the extension and the test method aren't otherwise directly connected.
• No surefire-reports directory after running — Confirm you're running via `mvn test` (which invokes Surefire) rather than running the test class directly through an IDE, which may not produce the same Maven-managed report output.

Extension challenge

Configure a GitHub Actions (or equivalent) workflow file that runs `CI=true mvn test` on every push, uploading target/surefire-reports/ and any failure-*.png files as CI artifacts, so a failure's screenshot is genuinely retrievable from the CI run itself, not just from a local machine.