Using Copilot to write Selenium tests (2026)

TL;DR

Using Copilot to write Selenium tests works best when Copilot receives a precise behavior contract plus repository-specific rules. Ask for one small change, inspect the diff, run the test, and reject code that hides synchronization, state, or assertions.

Key Takeaways

• Give Copilot the page contract, framework constraints, and expected behavior before requesting code.
• Generate one thin vertical scenario before asking for page objects, fixtures, data providers, or CI.
• Use repository instructions to encode approved Selenium, waiting, locator, and cleanup conventions.
• Compile and run every generated change, because plausible code is not evidence of a valid test.
• Keep assertions in tests and expose business services from page objects.
• Reject fixed sleeps, mixed wait strategies, shared drivers, hidden assertions, and broad exception handling.
• Review generated tests for risk coverage and observability, not only syntax.

Using Copilot to write Selenium tests can shorten the path from a clear test idea to compiling Java, but the quality comes from the test contract and review loop, not from autocomplete alone. Give Copilot the application behavior, DOM evidence, framework versions, locator policy, synchronization rule, and acceptance checks. Then treat every generated line as untrusted production test code until it compiles, runs, and survives review.

This guide uses GitHub Copilot as an implementation assistant for Selenium WebDriver with Java and JUnit. You will build one runnable browser test, add repository instructions, separate page behavior from assertions, diagnose weak output, and define a practical quality gate. The workflow is intentionally incremental. A small verified slice gives the model better local patterns for the next change and gives the engineer a clear place to stop when the output is wrong.

TL;DR

The useful mental model is intent -> constrained draft -> executable evidence -> reviewed change. Copilot is strong at following an established pattern. It is much less reliable when it must guess the product contract, current DOM, test data lifecycle, and team architecture at the same time.

1. Using Copilot to Write Selenium Tests Starts With a Test Contract

A vague request such as write login tests leaves almost every important decision unstated. Copilot must guess the URL, user states, locator strategy, success signal, failure behavior, test runner, driver lifecycle, and whether credentials may appear in code. A detailed prompt is not ceremony. It is the executable design input that prevents those guesses.

Write the contract in four blocks. First, state the observable behavior: a valid user submits credentials and reaches an authenticated page. Second, provide evidence: relevant HTML, API fixture, existing page object, or a neighboring test. Third, constrain the implementation: Java 17 or later, Selenium 4, JUnit Jupiter, explicit waits, and a fresh driver per test. Fourth, define acceptance: the test compiles, uses no fixed sleeps, cleans up in @AfterEach, and asserts a user-visible result.

A strong first prompt could be:

Create one Selenium Java test for the public Selenium web form.

Constraints:
- Use JUnit Jupiter and Selenium WebDriver.
- Create a fresh ChromeDriver in @BeforeEach and quit it in @AfterEach.
- Navigate to https://www.selenium.dev/selenium/web/web-form.html.
- Locate the text field by name "my-text" and the submit button by CSS selector "button".
- Enter "Copilot review", submit, and explicitly wait for id "message".
- Assert that the message text is "Received!".
- Do not use Thread.sleep, implicit waits, PageFactory, retries, or exception swallowing.
- Return only the proposed Java file and explain any assumption after the code.

This prompt gives Copilot a bounded task and makes review objective. For Selenium fundamentals before adding AI, see the getting started with Selenium guide.

2. Choose the Right Copilot Interaction for Each Testing Task

Copilot offers several interaction styles, and they should not all receive the same scope. Inline completion is useful when the file already establishes a strong local pattern. Chat is better for comparing designs, explaining a failure, or drafting a focused method. Agent-style workflows can inspect multiple files, edit code, and run commands, so they require a narrower definition of done and a deliberate diff review.

Start with a read-only planning request when the feature is unfamiliar: ask Copilot to identify existing driver setup, page patterns, test data helpers, and CI commands, without changing files. Review that inventory. Next request a single scenario. Only after it passes should you ask for a page object extraction or parameterized cases.

This sequencing reduces simultaneous uncertainty. If a generated test fails, you can tell whether the problem entered during scenario implementation or during abstraction. It also makes prompts reusable. The test lead can review the contract before any code is written, while the author remains accountable for every change that reaches the branch.

Do not confuse an agent's ability to run mvn test with permission to make arbitrary fixes. State which files may change, which commands may run, and which public interfaces must remain stable. Ask for a summary of assumptions and test output, then independently inspect the actual diff.

3. Configure a Current, Runnable Selenium Java Project

A generated test is useful only if its dependencies and runtime match the repository. The following Maven project uses Selenium 4.44.0, the stable Selenium release available in July 2026, and JUnit Jupiter 6.1.1. JUnit 6 requires Java 17 or later. Selenium Manager is used by the bindings when new ChromeDriver() needs a compatible driver, so the example does not hardcode a driver executable path.

Create pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.qajobfit</groupId>
  <artifactId>copilot-selenium-example</artifactId>
  <version>1.0.0</version>

  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-java</artifactId>
      <version>4.44.0</version>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>6.1.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.4</version>
      </plugin>
    </plugins>
  </build>
</project>

Pinning versions makes the example reproducible. In a real repository, follow its dependency management rather than adding a second version source. Ask Copilot to read the existing build file before proposing upgrades. Dependency changes deserve their own review because an unrelated version bump can mask the quality of the test change.

Run mvn -q test after adding the test in the next section. Chrome must be installed and the environment must permit a browser process and network access to the public test page. In a locked CI worker, use an approved browser image or a configured remote WebDriver endpoint. Never let Copilot invent infrastructure assumptions to make a local snippet appear complete.

4. Generate One Thin Selenium Test and Verify It

Place this complete test at src/test/java/com/qajobfit/WebFormTest.java. It uses documented Selenium constructors, locators, WebDriverWait, and JUnit lifecycle methods. The try/finally responsibility is expressed through @AfterEach, so cleanup runs even when the assertion fails.

package com.qajobfit;

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.time.Duration;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

class WebFormTest {
  private WebDriver driver;

  @BeforeEach
  void startBrowser() {
    driver = new ChromeDriver();
  }

  @AfterEach
  void stopBrowser() {
    if (driver != null) {
      driver.quit();
    }
  }

  @Test
  void submittingTextShowsReceivedMessage() {
    driver.get("https://www.selenium.dev/selenium/web/web-form.html");

    driver.findElement(By.name("my-text")).sendKeys("Copilot review");
    driver.findElement(By.cssSelector("button")).click();

    String message = new WebDriverWait(driver, Duration.ofSeconds(5))
        .until(ExpectedConditions.visibilityOfElementLocated(By.id("message")))
        .getText();

    assertEquals("Received!", message);
  }
}

Run it from the project root:

mvn -q test

Review more than the green result. Confirm that one test created one driver, the browser closed, the explicit wait targeted the state needed by the assertion, and the assertion compared the correct value in expected-then-actual order. Inspect target/surefire-reports if the run fails.

Now give Copilot the real output, not a paraphrase. For example: The wait timed out at WebFormTest.java:35. Do not increase the timeout. Explain the likely state mismatch, identify what evidence to capture, and propose the smallest correction. That instruction directs diagnosis toward the condition instead of encouraging a larger timeout. If element discovery is the problem, the Selenium NoSuchElementException troubleshooting guide provides a focused debugging path.

5. Add Repository Instructions That Encode Test Engineering Rules

Repository instructions reduce repeated prompt text and make good patterns visible to Copilot. GitHub documents .github/copilot-instructions.md for repository-wide guidance and .github/instructions/*.instructions.md for path-specific guidance in supported environments. Keep rules short, local, and verifiable. They should describe this repository, not generic advice that the model already knows.

A focused .github/instructions/selenium.instructions.md can look like this:

---
applyTo: "src/test/java/**/*.java"
---

# Selenium test rules

- Use Java 17 or later, Selenium 4, and JUnit Jupiter.
- Create a fresh WebDriver per test and always call quit during teardown.
- Prefer stable id, name, or team-owned data-test attributes.
- Use WebDriverWait for a specific observable state.
- Never add Thread.sleep or mix implicit and explicit waits.
- Keep assertions in test classes, not page objects.
- Page object methods expose user or business services, not raw WebElements.
- Test data must be unique, created through approved fixtures, and cleaned up.
- Never place credentials, tokens, customer data, or session cookies in prompts or code.
- Run mvn test after edits and report the exact command and result.
- Do not add retries unless the task explicitly requests an investigated retry policy.

Rules are valuable because they turn review findings into preventive context. If reviewers repeatedly remove static driver fields, add the lifecycle rule once. If the application uses data-testid, document its ownership and naming pattern. Include one correct neighboring example by path when it is stable.

Do not overload the instruction file with entire framework documentation. Large, conflicting rule sets reduce relevance and become stale. Review them like source code, with an owner and change history. Also verify whether the Copilot surface you use supports each instruction type. Support differs among GitHub.com, VS Code, JetBrains, Visual Studio, Eclipse, Xcode, and CLI, so a rule file existing in the repository does not prove every interface applied it.

6. Prompt for Page Objects Without Generating an Abstraction Maze

Once the thin test passes, abstraction can remove repeated UI mechanics. Ask Copilot to extract only the behavior that already exists. A page object should model services offered by the page, while the test retains assertions. It should not expose WebDriver, return raw elements, or become a dumping ground for generic clicks.

A useful extraction prompt is: Refactor only WebFormTest into a WebFormPage and the test. Preserve the existing behavior and locators. The page constructor accepts WebDriver, open() returns WebFormPage, enterText(String) returns WebFormPage, submit() returns WebFormPage, and messageText() explicitly waits for the visible message. Keep assertEquals in the test. Do not create BasePage, utilities, factories, or additional dependencies.

The narrow API prevents Copilot from introducing speculative layers. The resulting design should resemble:

package com.qajobfit;

import java.time.Duration;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

final class WebFormPage {
  private final WebDriver driver;
  private final WebDriverWait wait;

  WebFormPage(WebDriver driver) {
    this.driver = driver;
    this.wait = new WebDriverWait(driver, Duration.ofSeconds(5));
  }

  WebFormPage open() {
    driver.get("https://www.selenium.dev/selenium/web/web-form.html");
    return this;
  }

  WebFormPage enterText(String value) {
    driver.findElement(By.name("my-text")).sendKeys(value);
    return this;
  }

  WebFormPage submit() {
    driver.findElement(By.cssSelector("button")).click();
    return this;
  }

  String messageText() {
    return wait.until(
        ExpectedConditions.visibilityOfElementLocated(By.id("message"))
    ).getText();
  }
}

The test now reads as intent: open, enter text, submit, assert message. Avoid asking Copilot to create a full framework from one scenario. Framework design should emerge from repeated behaviors, execution constraints, and evidence needs. Premature base classes tend to hide Selenium and make failure messages less direct.

7. Review Generated Locators, Waits, State, and Assertions

The highest-risk Selenium defects are often plausible, compiling lines. Review generated output by concern rather than reading only from top to bottom. Start with locators. Ask whether each locator identifies a stable product concept and whether it is unique in the relevant scope. Long absolute XPath expressions, text tied to localization, and generated CSS classes deserve rejection unless the application leaves no better contract.

Next review synchronization. Every wait should name the state required by the next action: visible, clickable, absent, text changed, URL changed, or a product-specific condition. Thread.sleep guesses time. An explicit wait observes state. Selenium warns against mixing implicit and explicit waits because combined timing can be unpredictable. A timeout increase is not a root-cause fix.

Review state ownership. A static shared driver, shared mutable user, or ordered test dependency can make a suite pass serially and fail in parallel. The generated test should create or identify its own data, avoid relying on previous tests, and release browser and server-side resources. Secrets should come from the runtime environment or an approved secret store, never from a prompt transcript or source file.

Finally inspect assertions. A test needs a meaningful oracle, not just a click that does not throw. Assert the product-visible result and important side effects. For a checkout, that may include order status, total, and inventory behavior. For a rejected action, verify the state did not change. Copilot can write fluent syntax while omitting the business risk. The engineer must restore that intent.

Use a checklist in the pull request: locator contract, wait condition, data isolation, cleanup, assertion strength, negative side effects, diagnostics, and cross-browser scope. This is more reliable than asking whether the AI code looks good.

8. Debug Copilot Output With Evidence, Not Prompt Guessing

When generated code fails to compile, copy the exact compiler diagnostic plus the relevant dependency file and source region into the next request. Ask Copilot to explain the mismatch before editing. Compilation failures frequently reveal an API from another language binding, an outdated method signature, a missing import, or a JUnit version assumption.

When the browser test fails, classify it first:

A productive diagnostic prompt is: Here is the exact stack trace, current URL, screenshot description, and DOM around the target. Identify the first failed assumption. Suggest one observation to confirm it, then the smallest code change. Do not add sleeps, retries, JavaScript execution, or broad catches. This keeps the model in an evidence-driven loop.

If the test passes locally but fails in CI, compare environment facts before changing code. Headless viewport, locale, time zone, browser build, network access, test data, and parallel worker count can all expose a hidden dependency. Capture those facts in artifacts. Ask Copilot to help compare logs, but do not let it label a failure as infrastructure without evidence.

For broader reliability techniques, use the flaky test debugging guide. A generated retry can make a dashboard greener while removing the signal needed to fix the system.

9. Using Copilot to Write Selenium Tests for Coverage, Not Volume

After one scenario works, the tempting prompt is generate all edge cases. That usually creates many syntactic variations with weak risk differentiation. Instead, give Copilot a decision model and ask it to find missing combinations. AI is useful for expanding a structured test design, but the product owner and tester must decide which risks justify browser-level automation.

For a login feature, provide factors such as account status, credential validity, multi-factor requirement, rate limit state, and expected destination. Ask for a compact decision table with invalid combinations removed and each row tied to an observable outcome. Review it for requirements that are uncertain. Then choose a small browser set and push rule combinations to faster service or unit tests where possible.

Ask Copilot to label every proposed test with:

1. the risk it detects,
2. the unique precondition,
3. the observable oracle,
4. the cheapest reliable layer,
5. required test data,
6. why an existing test does not cover it.

This prompt discourages clone tests. It also makes deletion easier because duplicated purpose becomes visible. A UI suite should protect integrated user journeys, browser behavior, and critical presentation contracts. It should not repeat every validation already proven below the UI.

Use parameterization only when the workflow and oracle are genuinely the same. If each row needs branching setup and assertion logic, separate scenarios or move the combinations to an API-level test. The goal is a small diagnostic suite, not maximum generated line count. Copilot accelerates code production, so the review process must apply stronger pressure to keep only valuable code.

10. Build a CI and Review Gate for AI-Assisted Selenium Code

AI-assisted code should pass the same gate as human-written code, with added provenance and review attention where appropriate. The baseline gate includes formatting, compilation, targeted execution, full relevant regression, and artifact capture. Run tests in a clean environment so undeclared local state cannot rescue the generated change.

A simple GitHub Actions job can execute the Maven suite:

name: selenium-tests

on:
  pull_request:
  workflow_dispatch:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v5
        with:
          distribution: temurin
          java-version: "17"
          cache: maven
      - name: Run Selenium tests
        run: mvn -B test

The workflow is only a starting point. Browser availability, headless options, artifact upload, remote Grid use, and secret handling must match the repository. Pin or govern reusable actions according to organizational policy.

Add a repeated-run check before calling a previously unstable scenario fixed. Repetition does not prove determinism, but it can expose obvious order or timing sensitivity. Record run count and environment rather than publishing a fake universal confidence percentage. Quarantine is a temporary operational control with an owner and expiry, not a quality outcome.

During review, require the author to explain the test's risk, data lifecycle, synchronization points, and failure evidence. The author may say Copilot drafted the code, but cannot delegate accountability to it. Generated code can be accepted when the same evidence would justify hand-written code: current API use, clear design, reliable execution, meaningful coverage, and maintainable diagnostics.

Interview Questions and Answers

Q: How would you use GitHub Copilot to create a Selenium test safely?

I would first provide a bounded behavior contract, relevant DOM or existing patterns, framework constraints, and an observable expected result. I would ask for one scenario, inspect the diff, compile it, and run it in the intended environment. I would specifically review locators, waits, state isolation, teardown, and assertions. Copilot produces a draft, while I own the test design and the decision to merge it.

Q: Why is a compiling AI-generated Selenium test still insufficient?

Compilation only proves that the language and referenced APIs are acceptable to the compiler. It does not prove the locator identifies the right element, the assertion represents the requirement, data is isolated, or the test is stable under CI timing. I need executable results and a risk-based review. I also inspect failure diagnostics because a green test that cannot explain a later failure is expensive to maintain.

Q: What prompt details improve generated Selenium code most?

The strongest details are the exact behavior, DOM facts, existing file paths, dependency versions, lifecycle rules, forbidden patterns, and definition of done. I also state which files may change and the command that must pass. This removes choices the model should not guess. Examples from the same repository are usually more valuable than generic prose.

Q: How do you prevent Copilot from adding flaky waits?

I encode an explicit-wait policy in repository instructions and repeat the specific awaited state in the task. I reject Thread.sleep, mixed implicit and explicit waits, and timeout increases without evidence. During review, I connect each wait to the next action or oracle. If a timeout occurs, I inspect the actual page state before changing duration.

Q: Should page objects contain assertions generated by Copilot?

Generally, no. Page objects expose page or component services and hide DOM mechanics, while tests own assertions about the behavior under test. A page object may verify that it was instantiated on the expected page by failing fast, but it should not decide business correctness. Keeping assertions in tests makes intent and failure ownership visible.

Q: How would you review a large Copilot-generated Selenium pull request?

I would first reduce it into logical slices and identify changes outside the requested scope. Then I would review build changes, driver lifecycle, locators, waits, data, assertions, error handling, and CI separately. I would run targeted tests followed by relevant regression in a clean environment. If the change is too broad to reason about safely, I would ask for smaller commits or a smaller pull request.

Q: Can Copilot decide what should be automated at the UI layer?

It can suggest candidates, but it does not own the product risk model or execution economics. I ask it to map each case to a risk, oracle, data need, and cheapest reliable layer. I then choose UI cases for integrated journeys and browser-specific behavior. Many rule combinations belong in faster tests below the UI.

Q: What security controls matter when prompting Copilot with test context?

I never include production credentials, access tokens, private customer data, session cookies, or unredacted logs. I follow the organization's approved Copilot configuration and data policy. Prompts should use synthetic examples and minimized evidence. Generated code is also scanned for hardcoded secrets and unsafe logging before merge.

Common Mistakes

• Starting with a framework-sized prompt. Asking for pages, factories, listeners, reporting, parallelism, and CI at once produces too many unverified decisions. Build one working scenario, then extract only repeated behavior.
• Providing no product oracle. A generated test that clicks successfully may still test nothing. State the expected visible result and important side effects.
• Trusting plausible imports. Models can mix Selenium languages, old APIs, and helper libraries not present in the repository. Compile against the actual locked dependencies.
• Accepting fixed sleeps. A sleep neither observes readiness nor explains failure. Wait for a specific condition and capture state when it times out.
• Using JavaScript click as a universal repair. It can bypass the user interaction semantics the test is meant to validate. Diagnose overlays, visibility, scroll, and enabled state first.
• Sharing one mutable driver across parallel tests. Shared browser state creates ordering and concurrency defects. Use a driver lifecycle aligned with the runner's parallel model.
• Putting assertions inside every page method. Hidden assertions make page reuse and failure intent unclear. Return state to the test for verification.
• Generating many nearly identical cases. More code increases runtime and maintenance without necessarily increasing risk coverage. Require a unique purpose for every scenario.
• Sending sensitive evidence in prompts. Screenshots, logs, and fixtures can contain secrets or personal data. Redact and minimize context before sharing it with any AI tool.
• Letting retries replace investigation. A retry may reduce visible failures while preserving the race, data leak, or environment dependency. Use repeated execution for diagnosis, not concealment.

Conclusion

Using Copilot to write Selenium tests is effective when the engineer supplies the missing judgment: product intent, architecture constraints, reliable synchronization, data ownership, and meaningful oracles. Start with one constrained scenario, make it run on current dependencies, and let verified repository patterns guide later generation.

Your next step is to choose one small existing manual scenario, write its behavior contract, and ask Copilot for only the first executable slice. Review the resulting test with the locator, wait, state, assertion, and cleanup checklist before expanding the suite.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Using ChatGPT to write Playwright tests (2026)
• How to Run tests in headed mode in Selenium (2026)
• How to Scroll to an element in Selenium (2026)
• How to Skip and group tests in Selenium (2026)
• How to Use Selenium DevTools in Selenium 4 in Java (2026)
• Generating Selenium tests with AI (2026)