Playwright Automation with TypeScript: E2E, CI/CD, AI, MCP

A complete environment setup from scratch — installing Node.js, configuring VS Code with the right extensions, setting up TypeScript, and writing your first Hello World program. Students leave this lecture with a working development environment and the confidence that everything is connected correctly before writing a single line of automation code.

let, const, var — what they mean and when to use each. First look at how TypeScript adds safety on top of JavaScript.

string, number, boolean, any, void. How TypeScript uses types to catch errors before your tests even run.

Arithmetic, comparison, and logical operators. The building blocks of every condition and assertion you'll write.

if, else, else if, ternary expressions. Writing tests that respond to what the application actually does.

for, while, forEach. Iterating over lists of items — essential for validating search results, carts, and dynamic content.

String methods, template literals, and interpolation. Extracting and comparing text the way Playwright tests constantly require.

Declaring functions, parameters, return types. Writing reusable blocks of automation logic.

Arrow functions, optional parameters, callbacks. The function patterns Playwright uses internally — demystified.

A first look at classes and objects without the architecture. Planted here so POM in Phase 2 feels like a natural return, not a new concept.

Not a tool pitch — an honest look at what test automation solves, where it fails, and what it demands from the person writing it.

The difference between a test, a test file, and a framework. What students are actually building across this course

How each tool emerged from the limitations of the previous one. Why the history matters for understanding Playwright's design decisions.

Auto-waiting, multi-browser, network interception, parallel execution, built-in assertions. A technical look at what Playwright does that others don't.

How Playwright fits into AI-augmented workflows — codegen, Copilot-assisted test writing, and what this means for automation engineers entering the industry now

npm init playwright@latest — what gets installed, what each file does, and how to verify everything is working.

playwright.config.ts line by line. Base URL, browser projects, timeouts, reporters. Understanding config now prevents confusion throughout the course.

What actually happens when a test runs — browser launch, navigation, actions, assertions, teardown. Execution as a mental model, not just a command.

Why Playwright is async, what a Promise is in plain terms, and what breaks when you forget await. Exactly enough JavaScript to not be blocked.

What Playwright checks before acting on an element — visible, stable, enabled, receiving events. Why most explicit waits are unnecessary and when they're not.

expect() and why Playwright retries assertions until they pass or time out. The difference between a flaky assertion and a broken one.

This section introduces students to how web pages are structured, how to identify elements, and how to build their first real Playwright test workflows using different locator strategies. Overview of the practical automation workflows students will create in this section. Introduces the concepts of DOM inspection, locators, assertions, login automation, workflow automation, and Playwright's locator strategy.

Learn how web pages are structured using the Document Object Model (DOM) and understand the fundamentals of CSS selectors. Students learn how elements are represented in HTML and how selectors can be used to target them.

Hands-on walkthrough of inspecting web elements using Chrome DevTools and SelectorHub. Students learn how to locate element attributes, validate selectors, and analyze page structure for automation.

Applying CSS selectors on a practice site before touching the demo store. A controlled environment to make mistakes without breaking your real test suite.

Build the first complete Playwright test by automating a login workflow. Students use CSS selectors to interact with elements and add assertions to verify successful authentication.

Automate a billing address update workflow while learning advanced locator techniques. Covers parent-child locator relationships, scoping locators to specific sections, and creating more reliable element identification strategies.

Explore Playwright's recommended locator methods such as getByRole(), getByLabel(), getByText(), and other accessibility-driven locators. Learn how ARIA attributes improve test stability and maintainability.

Learn how to use Playwright Codegen to automatically generate test scripts. Students understand how generated code works, how to clean and refactor it, and when Codegen is most useful during test development.

Apply Codegen to automate a complete end-to-end checkout process. Students learn how to transform generated code into a maintainable test while reinforcing locator usage, assertions, and workflow automation concepts.

Renaming tests to describe behavior, wrapping logical actions in test.step(), and grouping related tests with test.describe. How this changes what reports look like.

@smoke, @regression, @critical — tagging tests so you can run meaningful subsets. Annotations for skipping, marking expected failures, and documenting known issues.

Extracting hardcoded values — usernames, passwords, product names, URLs — into data objects. Why mixing data with logic makes tests harder to read and harder to update.

Capturing text the application generates (order IDs, confirmation numbers) and using it in subsequent steps. Regex extraction and dynamic assertion strategies.

Live review of Phase 1 code highlighting exactly where it breaks down — no environment strategy, no execution control, no CI readiness, auth on every test, no separation of concerns. Students see the problems themselves before being given the solutions

Learn what fixtures are in Playwright and why they are a powerful mechanism for sharing setup and test resources. Understand how fixtures help reduce code duplication and create cleaner, more maintainable test suites.

Create your first custom Playwright fixture and learn how fixtures can provide reusable objects and functionality to tests. Students see how custom fixtures improve readability and simplify test setup.

Build an authentication setup workflow that performs login once and saves the authenticated session. Students learn how to generate storage state files and use them to bypass repetitive login steps in future test executions.

Live review of the current framework highlighting every hardcoded value — credentials in source code, URLs scattered across four files, test data mixed with test logic. Students see the problems themselves before getting the solutions. Sets up the next four lectures.

Moving credentials and environment configuration out of source code. dotenv setup, BASE_URL in playwright.config.ts, process.env in auth.setup.ts. Startup validation that fails fast when variables are missing. Special characters in passwords. dotenv 17.x verbose output and how to suppress it

Driving the same test with multiple data combinations using forEach. Why test.each has TypeScript limitations with custom fixture types and forEach is the reliable alternative. Named test runs in the HTML report. Adding a new scenario by editing JSON — no spec file changes needed.

When JSON is not enough — business analysts and QA leads who own test data in spreadsheets. SheetJS for Excel, Node fs for CSV. TypeScript types in utils/types.ts — what export type means, named exports, named imports with curly braces. The generic reader pattern. When to use JSON versus Excel versus CSV.

Students learned classes there without context. Now the context arrives. A class represents a page. Properties hold locators. Methods represent user actions. The mental model before any code.

The problem POM solves — locators in spec files, one UI change breaks multiple files. The pattern — one class per page, locators defined once, methods encapsulate actions. What belongs in a page class and what never does. Short conceptual lecture before building.

Create pages/AddressPage.ts. More complex — multiple form fields, navigation, verification. Extract all locators from profile.validation.spec.ts into the class. Methods: navigate(), editBillingAddress(), verifyAddress().

Create pages/OrdersPage.ts. Extract order history navigation and order verification from checkout.journey.spec.ts. Completes the page object coverage for all real test flows.

What belongs in a page class — locators, action methods, navigation. What never belongs — test data, assertions that are test-specific, test logic. Method naming conventions. How to handle pages that share common elements like the navigation bar. Common mistakes — over-engineering, under-engineering, putting assertions in page objects.