Selenium Java Tutorial: Automate User Signup Form Testing

This Selenium Java tutorial shows the browser-automation flow for testing a user signup form: open the page, locate its controls, enter test data, submit, wait for an observable outcome, assert the result, and close the browser. The code below first uses Selenium’s generic sample web form. That sample demonstrates WebDriver interactions; it is not a signup service and does not define account-creation rules.

To test a real signup page, replace the sample URL and locators with the target application’s documented form, then assert behavior that belongs to that application’s contract. Do not treat a generic result message as proof that an account was created or persisted.

1. Set up a Java project

You need a Java development environment, a project build tool such as Maven or Gradle, Selenium’s Java bindings, and a browser supported by your Selenium setup. Selenium’s official first-script walkthrough uses ChromeDriver. Driver availability and setup can depend on your local Selenium and browser versions, so follow the current Selenium installation guidance for your environment.

The source material for this tutorial does not establish a verified dependency version or a particular test framework. Add the Selenium Java dependency using the version and build instructions you have chosen from the official documentation. The example below is a plain Java class with a main method, so it does not require JUnit or TestNG.

2. Run the basic Selenium Java form example

This runnable example follows Selenium’s first-script flow on its sample web form: create a Chrome driver, navigate to the sample, find a text field and submit button, enter text, submit, read the result, and close the browser. It verifies only that the sample displays its expected message.

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

import java.time.Duration;

public class SignupFormFlow {
    public static void main(String[] args) {
        WebDriver driver = new ChromeDriver();

        try {
            driver.get("https://www.selenium.dev/selenium/web/web-form.html");

            WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
            WebElement textField = wait.until(
                ExpectedConditions.visibilityOfElementLocated(By.name("my-text"))
            );
            WebElement submitButton = wait.until(
                ExpectedConditions.elementToBeClickable(By.cssSelector("button"))
            );

            textField.sendKeys("signup test example");
            submitButton.click();

            WebElement result = wait.until(
                ExpectedConditions.visibilityOfElementLocated(By.id("message"))
            );
            String actualMessage = result.getText();
            String expectedMessage = "Received!";

            if (!expectedMessage.equals(actualMessage)) {
                throw new AssertionError(
                    "Expected message '" + expectedMessage + "' but got '" + actualMessage + "'"
                );
            }

            System.out.println("Sample form interaction succeeded: " + actualMessage);
        } finally {
            driver.quit();
        }
    }
}

Here, finally ensures quit() runs if an interaction or assertion fails. A driver session left open can consume local resources and interfere with later runs. Selenium’s sample form and its “Received!” message are not evidence of real signup success.

3. Adapt the flow to a real signup page

Before writing signup assertions, identify the target page’s real controls and documented outcomes. The title does not specify an application, so no universal field names, password rules, validation messages, duplicate-account behavior, or success destination can be assumed.

1. Choose a permitted test environment. Use an application and test accounts you are authorized to exercise. Avoid creating uncontrolled accounts on a production service.
2. Inspect the form markup and contract. Determine the actual email, password, submit, and feedback elements, plus required fields and expected outcomes.
3. Use test data appropriate to the environment. Avoid real personal information. If the application requires unique addresses, use the test system’s supported address strategy and cleanup process.
4. Replace sample locators. Use selectors grounded in the page markup and check that each identifies the intended control.
5. Wait for a meaningful result. This may be a confirmation element, an inline validation error, a changed URL, or another documented state.
6. Assert the contract. Check the expected outcome and, where the test environment supports it, verify the resulting account state through an approved test interface.

For example, the following locator lines are placeholders, not selectors verified against a particular signup page:

WebElement email = wait.until(ExpectedConditions.visibilityOfElementLocated(
    By.cssSelector("input[name='email']")
));
WebElement password = wait.until(ExpectedConditions.visibilityOfElementLocated(
    By.cssSelector("input[name='password']")
));
WebElement submit = wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("button[type='submit']")
));

email.sendKeys("signup-test@example.invalid");
password.sendKeys("replace-with-test-only-password");
submit.click();

// Replace this selector and expected state with the target application's contract.
WebElement confirmation = wait.until(ExpectedConditions.visibilityOfElementLocated(
    By.cssSelector("[data-testid='signup-confirmation']")
));
if (!confirmation.isDisplayed()) {
    throw new AssertionError("Expected signup confirmation to be visible");
}

The .invalid domain is reserved for invalid examples and will not receive mail. A real end-to-end test that needs email verification must use a test environment’s documented mail capture or verification mechanism. Do not claim account creation from a visible confirmation alone unless that is the behavior the test is intended to verify.

4. Choose maintainable locators

Selenium supports several locator strategies. Its documentation lists traditional strategies including ID, name, CSS selector, class name, link text, and others. Select based on the actual markup and whether the locator unambiguously identifies the intended control.

Strategy	Example	Use when
ID	By.id("email")	The element has a stable, unique ID.
Name	By.name("email")	The form control has a stable name attribute.
CSS selector	By.cssSelector("input[type='email']")	You need to match attributes or a relationship in the DOM.
Class name	By.className("submit-button")	A single class identifies the intended element; class names can be shared.
Link text	By.linkText("Create account")	The target is a link with stable visible text.

Prefer a locator that communicates intent and matches only the control under test. Broad selectors such as button can become ambiguous when a page adds a second button. If a selector stops matching, inspect the current page markup rather than guessing a replacement.

5. Wait for the page state you need

A completed navigation does not guarantee that JavaScript-driven changes or newly interactive controls are ready. Selenium documents timing races as a source of flaky tests. An explicit wait polls for a stated condition, so wait for the field before typing and the expected post-submit state before asserting it.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement field = wait.until(
    ExpectedConditions.visibilityOfElementLocated(By.name("my-text"))
);
WebElement button = wait.until(
    ExpectedConditions.elementToBeClickable(By.cssSelector("button[type='submit']"))
);

The timeout is a maximum for the condition, not a required pause. Choose a limit suitable for the application and environment. Avoid replacing condition-based synchronization with arbitrary sleeps: a fixed delay may waste time on fast runs and still be too short on slow ones.

For post-submit synchronization, wait for the actual observable result: visibility of a confirmation or error, a URL condition, or a state change defined by the application. If the application updates the same element in place, wait for its text or other expected property rather than waiting for a page load that will not occur.

6. Test signup cases deliberately

Once the target application’s rules are known, build cases around those rules. A useful suite might include a valid submission and relevant invalid inputs, but the exact cases and expected messages depend on that application.

Case	What to observe
Valid test data	The documented success state and, if required, account state in the test system.
Missing required value	The documented validation state and whether submission is blocked or rejected.
Malformed email or other invalid input	The application’s actual validation behavior.
Password boundary cases	Only the documented password policy and its expected feedback.
Existing account	The documented duplicate-account outcome in a controlled test environment.

Keep test setup and cleanup repeatable. Reusing an address may change a later run’s outcome; generating random accounts may create persistent test data. Prefer the target system’s documented fixture, reset, or cleanup approach.

7. Troubleshoot common failures

Symptom	Likely cause	Fix
Driver or browser cannot start	Browser, driver, Selenium, or local configuration is incompatible or unavailable.	Check the installed browser and Selenium setup against the current official installation guidance; confirm the browser can launch in the execution environment.
NoSuchElementException	The locator is wrong, the page differs, or the element has not appeared yet.	Inspect the actual DOM and locator; wait for the relevant condition when rendering is asynchronous.
TimeoutException	The expected condition never became true within the configured wait.	Check whether the selector and expected state are correct, whether the app returned a different validation state, and whether the environment is responding.
Click fails or the control is not interactable	The control is hidden, disabled, covered, or not yet ready.	Wait for visibility or clickability, inspect overlays and validation state, and target the correct control.
Test passes locally but fails intermittently	The test races asynchronous rendering or waits for the wrong state.	Wait for a specific UI condition and assert the application’s result rather than relying on navigation timing or a fixed sleep.
Signup succeeds once and fails later	Test data may persist, or the address may already exist.	Use the test environment’s documented data reset or unique test-data strategy, then clean up where supported.
Confirmation assertion fails	The sample message, placeholder selector, or assumed behavior does not match the target application.	Read the application contract and inspect its real result state; update the assertion to match observed, documented behavior.

8. Performance, reliability, and cost

Browser tests are useful when the behavior under test depends on a real browser interaction, such as filling and submitting the form. Keep each test focused, avoid unnecessary page reloads, and wait only for conditions the scenario needs. Reusing a browser session can reduce startup overhead in a larger suite, but isolate test data and browser state so one scenario does not affect another.

Reliability comes from stable selectors, condition-based waits, controlled test data, assertions tied to the application contract, and guaranteed driver cleanup. A screenshot can help diagnose a failed visual or browser state, but it does not replace assertions about validation or account state.

Browser execution has infrastructure and maintenance costs: a browser and driver must run in the chosen environment, tests consume execution time, and UI changes can require locator updates. Keep the suite proportional to the user flows it needs to protect, and run account-creation scenarios against an approved test environment.

9. Or skip the browser setup

For a screenshot of the page before or after a test, ScreenshotNeo is a website screenshot API and MCP server for developers. It takes one GET request with a URL and returns PNG, JPEG, WebP, or PDF. This does not submit a signup form or replace Selenium assertions. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server gives AI agents screenshot, page information, and PDF capture tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month with no card.

FAQ

Does the Selenium sample create a user account?

No. It submits text to Selenium’s generic sample web form and checks that form’s result message.

Can I use this without JUnit or TestNG?

Yes. The main example is a plain Java program. A test framework can be added when you want test discovery, setup and teardown hooks, or structured reports.

Does a screenshot prove that signup worked?

No. A screenshot records rendered page content. Verify signup behavior with assertions against the application’s documented UI and, when needed, its approved test data interface.

Official references

• Selenium: First script
• Selenium: Locator strategies
• Selenium: Waiting strategies