lecture 5 of 200 completed

Starting the browser and moving around

get, navigate, back and refresh. Plus the two options every real project sets, and why headless changes behaviour.

In Cypress and Playwright the browser appears and you never think about it. In Selenium you start it yourself, which means you also configure it and close it yourself.

Starting a session.

const driver = await new Builder().forBrowser('chrome').build();

That launches a real Chrome and connects to it. The driver object is your handle on that browser for the rest of the test.

Navigating.

await driver.get('http://localhost:3000/login');

get loads a page and waits for the initial load to finish. Note there is no baseUrl built in, so most teams keep the address in a config file or an environment variable and build the URL themselves.

The other movements:

await driver.navigate().back();
await driver.navigate().forward();
await driver.navigate().refresh();

refresh() earns its place in real tests. It is how you prove data was saved rather than just drawn on screen: create a contact, refresh, check the row is still there. Without the refresh you have only proved the app updated its own display, which it would do even if the save failed.

Checking where you are.

const url = await driver.getCurrentUrl();

Assert on this after any action that should navigate. It is the assertion that turns "element not found" into "we were still on the login page", which is a much more useful failure.

Options every real project sets.

const chrome = require('selenium-webdriver/chrome');

const options = new chrome.Options();
options.addArguments('--headless=new');
options.addArguments('--window-size=1920,1080');

const driver = await new Builder()
  .forBrowser('chrome')
  .setChromeOptions(options)
  .build();

Headless means no visible window. Faster, and required on build servers, which usually have no screen at all.

⚠️ Headless is not the same browser.

A suite that passes with a visible window can fail headless. The usual cause is window size: headless often defaults to a small viewport, so elements sit off screen or a responsive layout switches to its mobile version and your selectors miss.

Set the window size explicitly. It removes a whole category of "passes locally, fails in CI".

Window size matters for the same reason even with a visible browser. A test that depends on the window being a particular size will behave differently on a colleague's laptop. Set it and stop guessing.

Remember this: you start the browser, you set its size, and you assert the URL after navigating.

Reference: Browser navigation.