Selenium is the oldest of the three big tools, and it does the least for you. That sounds like bad news. It is actually why Selenium questions come up so often in interviews: nothing is hidden, so your answers show whether you really understand testing.
Here is the model. Your test is a program (here, Node.js) that talks to a driver. The driver controls a real browser. Every command, like find this element or click it, is a message sent to the driver.
const { Builder, By } = require('selenium-webdriver');
const driver = await new Builder().forBrowser('chrome').build(); // start a session
await driver.get('/'); // load a page
await driver.findElement(By.css('[data-testid="login-button"]')).click();
await driver.quit(); // end the session
Three things follow from this model, and they define what working with Selenium feels like:
Selenium does only what you say. There is no built-in retrying assertion and no automatic waiting for conditions (beyond an optional implicit wait for lookups). If the app needs a moment, you express the wait. If a value must be checked, you read it and assert it. This is more work than Playwright or Cypress. It is also why interviewers love Selenium questions, because nothing is hidden.
You bring your own assertions. Selenium drives the browser; a separate library proves things. In JavaScript that is usually Node's assert (or Chai):
const assert = require('assert');
assert.strictEqual(await badge.getText(), '1');
The session is a resource you manage. build() starts a browser and quit() ends it. Forget quit() and the browsers pile up.
This is not a small detail. I once helped a team whose build machine kept freezing. A broken test was leaving one Chrome process behind on every run. After two days there were over 200 of them. Always close the browser, and later you will learn where to put that code so it runs even when a test fails.
Two words you will meet constantly: findElement returns one element or throws if none matches; findElements returns a list that can be empty. That difference matters. It is how you check absence, and it comes back in a later lecture.
The official model overview: WebDriver documentation.
No problem for this one. It is the mental model the rest of the track stands on. The next lecture writes your first real test.