What Selenium is, and where it fits

Selenium is a tool that opens a web browser and performs the same actions a person would: clicking buttons, typing into forms, and reading what appears on the screen.

The difference is that it does this in a few seconds, and it does exactly the same thing every time.

Here is the problem it solves.

Say your site has a login page. You check it by hand. The correct password works. The wrong password shows an error. It works, so you move on.

Two weeks later, someone edits a piece of code that the login page shares with another screen. Login quietly breaks. Nobody checks it, because login already worked. A customer finds it on Monday morning.

Instead of repeating these checks by hand after every change, Selenium lets you describe them in code. The check is written once, and runs automatically from then on.

What a test looks like

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

await driver.get('http://localhost:3000/login');
await driver.findElement(By.css('[data-testid="email"]')).sendKeys('demo@example.com');
await driver.findElement(By.css('[data-testid="password"]')).sendKeys('wrong-password');
await driver.findElement(By.css('[data-testid="submit"]')).click();

const error = await driver.findElement(By.css('[data-testid="error"]')).getText();
expect(error).to.equal('Incorrect password');

Read it from top to bottom.

• new Builder()...build() starts a browser. You do this yourself in Selenium, and you close it yourself too.
• driver is your handle on that browser.
• driver.get opens a page.
• findElement points at an element, meaning one thing on the page such as a button or a text box. The part inside By.css(...) describes which one you mean. Lecture 7 covers how to write those well.
• sendKeys types, and click clicks.
• expect(...) is the check.

Two things are already different from the other tools, and both are worth noticing now.

You start and stop the browser yourself. Selenium hands you that control, and the responsibility that comes with it.

The check comes from somewhere else. expect is not part of Selenium. Selenium controls browsers; deciding whether a value is correct is a separate job done by a separate library. There is a whole lecture on this, because it surprises everyone.

That last line is still the important one. Without it, the test clicks through the page and proves nothing.

A test is steps plus a check. The steps make something happen. The check decides whether it was right.

Where Selenium fits

Selenium interacts with your application through a browser, performing the same types of actions users perform: clicking, typing, and checking results.

This is called end-to-end testing, because it checks a complete user journey through your application, from the user's actions in the browser to the expected result.

Other kinds of tests exist. A unit test checks one function on its own, with no browser. Unit tests are faster and narrower. End-to-end tests are slower and closer to real life, so teams write a small number of them, covering the journeys that matter most, like signing in and paying.

Unlike the other two tools, Selenium does not wait for things automatically. You say when to wait, and for what. That is more work, and it is also why understanding waiting properly matters more here than anywhere else. Lecture 13 covers it.

Selenium is one of three tools you will see in job postings for this work. The others are Playwright and Cypress. They solve the same problem in different ways, and this site teaches all three.

Why Selenium is still everywhere

Selenium is the oldest of the three, and it is still the most widely deployed. There is a reason.

Selenium is built on a web standard called WebDriver, which browser makers implement themselves. That means Selenium works with more browsers, more programming languages and more operating systems than anything else. Java, Python, C#, JavaScript, Ruby. Chrome, Firefox, Safari, Edge.

If a company needs to test on a combination nothing else supports, Selenium is often the only option. That reach is what you are buying, and the extra work you do around waiting is what you pay for it.

One honest thing before you start

An automated test does not find new bugs. It cannot look at a screen and decide that the wording is confusing.

What it does is notice when something that used to work stops working. That is most of the value, and it is why a test written in March still earns its place in September.

Remember this: Selenium drives a real browser through your app, and the check at the end is what makes it a test.

Next: the apps you will practise on.

Reference: Selenium documentation