Module 3: TypeScript & JavaScript for Playwright

Playwright tests are programs, and the language they are written in is TypeScript—a typed layer on top of JavaScript. You do not need to be a full-stack developer to write excellent tests, but you do need a working command of a focused slice of the language: variables and types, functions and arrow syntax, the async/await model that underpins every browser action, and how modules import and export code. This module teaches exactly that slice, with every example aimed at testing. Get comfortable here and the rest of the course reads like plain English.

JavaScript and TypeScript, briefly

JavaScript (JS) is the language browsers run. Node.js lets it run outside the browser too, which is how Playwright executes your tests. TypeScript (TS) is JavaScript with a type system bolted on: you can annotate what kind of value a variable holds, and a compiler checks your code before it runs, catching whole classes of mistakes. TypeScript compiles down to ordinary JavaScript, so anything you learn about JS applies directly—TS just adds safety on top.

You chose TypeScript when initializing the project in Module 2, and this module shows why that was the right call.

Variables and types

Declare variables with const (a value that will not be reassigned) or let (one that will). Prefer const by default and only reach for let when you genuinely need to reassign. Avoid the old var entirely.

const baseUrl = 'https://example.com';   // will not change
let attempts = 0;                        // will be reassigned
attempts = attempts + 1;

// baseUrl = 'other';  // error: cannot reassign a const

TypeScript can often infer the type from the value, but you can also state it explicitly after a colon:

const username: string = 'qa_user';
const retryCount: number = 3;
const isHeadless: boolean = true;

// Arrays
const browsers: string[] = ['chromium', 'firefox', 'webkit'];

// Objects with a described shape
const credentials: { user: string; pass: string } = {
  user: 'qa_user',
  pass: 'secret123',
};

Those type annotations are the whole point of TypeScript. If you later write const retryCount: number = 'three', the compiler stops you before the test ever runs.

Functions and arrow functions

A function packages reusable logic. The traditional form uses the function keyword:

function buildUrl(path: string): string {
  return 'https://example.com' + path;
}

const loginUrl = buildUrl('/login');   // 'https://example.com/login'

Note the parameter type (path: string) and the return type (: string) after the parentheses. TypeScript will warn you if you return the wrong kind of value or pass the wrong kind of argument.

Modern JS favours the shorter arrow function, which you have already seen in every Playwright test:

// Same function as an arrow function
const buildUrl = (path: string): string => {
  return 'https://example.com' + path;
};

// For a one-line body you can drop the braces and 'return'
const double = (n: number): number => n * 2;

This is exactly the shape of a Playwright test body: test('name', async ({ page }) => { ... }). The async ({ page }) => { ... } part is an arrow function—now you can read it precisely.

Promises and async/await

This is the most important section in the module. Browser actions are asynchronous: clicking a button, loading a page, and reading text all take time, and JavaScript does not stop the world to wait. Instead these operations return a promise—an object representing a result that will arrive later.

If you ignore the promise, you move on before the action finishes, and your test checks a page that has not updated yet. The await keyword solves this: it pauses the function until the promise resolves, then hands you the result. await is only allowed inside a function marked async—which is why every Playwright test body is async.

test('reads the welcome message', async ({ page }) => {
  await page.goto('https://example.com/login');   // wait for navigation
  await page.getByLabel('Username').fill('qa_user'); // wait for the fill
  await page.getByRole('button', { name: 'Log in' }).click(); // wait for click

  // Now read text. textContent returns a promise, so we await it.
  const heading = await page.getByRole('heading').textContent();
  expect(heading).toContain('Welcome');
});

The rule of thumb for Playwright: if a call talks to the browser, await it. Navigation, actions, and locator queries like textContent() all return promises. The web-first expect(locator)... assertions are also awaited. The plain-value expect(heading) on a string you already have is not.

// WRONG: no await
test('bad', async ({ page }) => {
  page.goto('https://example.com');   // promise ignored!
  expect(page.getByText('Welcome')).toBeVisible(); // runs too early
});

Modules: import and export

Real test suites span many files: helpers in one file, page objects in another, test data in a third. ES modules let files share code. A file exports what it wants to share; another file imports it.

// file: helpers/urls.ts
export const BASE_URL = 'https://example.com';

export function loginUrl(): string {
  return BASE_URL + '/login';
}

// file: tests/login.spec.ts
import { test, expect } from '@playwright/test';
import { BASE_URL, loginUrl } from '../helpers/urls';

test('navigates to login', async ({ page }) => {
  await page.goto(loginUrl());
  await expect(page).toHaveURL(BASE_URL + '/login');
});

You have already used the named import form every time you wrote import { test, expect } from '@playwright/test'. A module can also have a default export—you will see export default defineConfig({ ... }) in playwright.config.ts in Module 5.

Why TypeScript helps in Playwright

You could write Playwright tests in plain JavaScript, but TypeScript pays for itself immediately in a test codebase.

• Autocomplete. Because Playwright ships rich type definitions, your editor knows every method on page and every option it accepts. Type page. and a complete, accurate list appears. You spend far less time hunting through documentation.
• Catching errors before they run. Misspell a method or pass the wrong option type and TypeScript flags it in the editor, not three minutes into a CI run. For a suite that takes time to execute, catching mistakes at write-time is a large saving.
• Safer refactoring. Rename a helper or change a page object’s method and the compiler shows you every call site that needs updating. This is what makes large suites maintainable.
• Self-documenting code. Types describe intent. A function typed (user: Credentials) => Promise<void> tells the next reader exactly what it expects and returns.