Frames, Windows and Tabs, and the Actions API

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 created in this course's first guided local lab.
2. Pick a real, publicly-accessible site with at least a two-step flow you're comfortable automating for practice (a search-then-click-a-result flow works well and is broadly available).

Project structure

selenium-learning-lab/
  pom.xml
  src/
    test/java/com/visaspark/selenium/
      MultiPageWorkflowTest.java

Starter files

package com.visaspark.selenium;

import org.junit.jupiter.api.*;
import org.openqa.selenium.*;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;
import java.time.Duration;
import static org.junit.jupiter.api.Assertions.*;

class MultiPageWorkflowTest {
    private WebDriver driver;
    private WebDriverWait wait;

    @BeforeEach
    void setup() {
        driver = new ChromeDriver();
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

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

    @Test
    void searchThenNavigateToAResult() {
        // TODO: navigate to your chosen site's starting page
        // TODO: use an EXPLICIT wait (wait.until(ExpectedConditions...)) before interacting
        //       with the search input -- do not use Thread.sleep
        // TODO: perform a search action
        // TODO: wait for and click a real result link
        // TODO: assert something about the resulting second page (title, a visible heading, or the URL)
    }
}

Requirements

• The test uses at least one explicit WebDriverWait with a specific ExpectedConditions call — no Thread.sleep anywhere.
• The test genuinely navigates across at least two distinct real pages/URLs.
• Locators use id, name, or cssSelector targeting meaningful attributes — no deep structural XPath.
• @BeforeEach/@AfterEach correctly create and tear down a fresh driver per test.
• The final assertion verifies something real and specific about the second page reached.

Commands to run

• Run the workflow test

  mvn test -Dtest=MultiPageWorkflowTest

Expected behavior

Running the test launches a real browser, performs the multi-step workflow with each step correctly waiting for real readiness (never a fixed sleep), navigates across at least two real pages, and passes with a specific, correct final assertion.

Verify it yourself

• mvn test -Dtest=MultiPageWorkflowTest

  Expected: BUILD SUCCESS; the browser is observed navigating across at least two distinct real pages during the run

• grep -n Thread.sleep src/test/java/com/visaspark/selenium/MultiPageWorkflowTest.java

  Expected: No output — confirms no fixed sleep was used anywhere in the test

Troubleshooting

• `TimeoutException: Expected condition failed` — Confirm the ExpectedConditions call matches an element that genuinely appears on the real page you're testing against — inspect the real page's HTML to confirm your locator strategy is correct.
• The test clicks the wrong result or a stale element — Re-locate elements freshly after any page transition rather than reusing a WebElement reference obtained on the previous page — see this course's element-location lesson on staleness.
• Test passes locally but is flaky in repeated runs — Confirm every interaction is preceded by an appropriate explicit wait (elementToBeClickable for things you click, visibilityOfElementLocated for things you just need to see) — a passing-but-flaky test often has one un-waited-for interaction.

Extension challenge

Extend the test to open a link that opens in a new tab (target="_blank"), switch WebDriver's focus to that new window using the getWindowHandles() diffing pattern from this lesson, assert something on it, then explicitly switch back to the original window handle.