A successful login is more than a valid password check: a member must be able to enter credentials in the browser and reach the right account page. Selenium WebDriver automates that visible journey by launching a real browser, interacting with the page, and inspecting the result. It is useful when the UI behavior itself matters; business rules that do not require a browser are better tested below the UI layer. section 10.2.7 section 10.0
A test uses a language-specific WebDriver client to communicate with a browser-specific driver through the W3C WebDriver protocol. The same approach supports browsers including Chrome, Firefox, and Microsoft Edge; Selenium Grid can control remote browsers. Java is one option among several supported languages. section 10.2.6
A typical browser step follows this flow:
- Open the application with `driver.get()`, then locate a page element with `findElement()`. section 10.2.11
- Use the returned `WebElement` to click, type with `sendKeys()`, or read text and attributes. Clear a field first if existing text must be replaced. section 10.2.11 section 10.2.13
- Assert the visible outcome, such as the signed-in member’s email on the account page. section 10.2.11
@When("{} logs on with a valid username and password")
public void logsOnWithAValidUsernameAndPassword()
WebDriver driver = WebTestSupport.currentDriver();
driver.get("http://localhost:3000"); #1
driver.findElement(By.linkText("Login")).click(); #2
driver.findElement(By.id("email")).sendKeys(frequentFlyer.email); #3
driver.findElement(By.id("password")).sendKeys(frequentFlyer.password); #3
driver.findElement(By.id("login-button")).click(); #4
}
This login step opens the site, follows the Login link, fills credentials using element IDs, and submits the form. section 10.2.11
For a registration form, locators can target IDs, CSS selectors, or XPath expressions. `Keys.TAB` can complete a keyboard interaction, and `Select` can choose a visible option. Meaningful IDs or CSS classes make these tests easier to sustain. Wait conditions help when an asynchronous page has not yet reached the expected state. section 10.2.13 section 10.5
Browser tests can capture screenshots for reports or illustrated documentation, but too many can slow the suite and create a maintenance burden. Keep them focused on important UI interactions and end-to-end journeys. section 10.2.6 section 10.5
