Playwright Automation Testing: TypeScript, CI/CD, API, AI

Set up Playwright from scratch using npm init playwright@latest. Learn Playwright installation, project scaffolding, browser binaries setup, and TypeScript configuration so you're ready to write automated tests in minutes.

Understand the Playwright project structure and the playwright.config.ts file. Learn how projects, timeouts, and the reporter settings control test execution, and how to configure Playwright for real-world automation testing.

Run your first Playwright test and explore the built-in HTML test report. Learn the test execution lifecycle, how to read pass/fail results, and how Playwright's reporting helps you debug automated tests faster.

Use the Playwright VS Code extension, Test Explorer, and UI Mode to run, debug, and inspect tests visually. A must-know workflow for efficient Playwright test automation and debugging in your IDE.

Write your first real Playwright test against a live e-commerce demo site (qa-cart.com). Learn locators, navigation, and assertions in a practical, hands-on Playwright automation testing example.

Master async/await in Playwright and TypeScript. Understand synchronous vs asynchronous code, why tests fail without proper awaiting, and how Playwright handles asynchronous browser automation under the hood.

Learn Playwright's auto-wait mechanism and web-first assertions with expect(). Understand actionability checks, auto-retrying assertions, and how to write reliable, flake-free Playwright tests.

Discover why Playwright has become a leading test automation framework: auto-wait, one-command browser installation, cross-browser support, trace viewer, parallel execution, multi-language support, and built-in API testing capabilities

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.

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.

Code recap for this lesson

This is the code of the max price step exactly as written in the video, with the parts that were only spoken written out.

await test.step('Apply maximum price filter', async () => {

  await page.getByRole('textbox', { name: 'Filter products by maximum' })

    .fill(testData.search.maxPrice);

  // "$25" is text. Remove the "$" and convert to the number 25 so we can compare.

  const maxPriceNum = Number(testData.search.maxPrice.replace('$', ''));

  // Wait until the filter label "Up to $25" is on the page.

  await page.getByText(`Up to $${maxPriceNum}`).waitFor({ state: 'visible' });

  // Same product locator as the search step.

  const products = page.locator("ul.products li");

  await products.first().waitFor({ state: 'visible' });

  const count = await products.count();

  for (let i = 0; i < count; i++) {

    const product = products.nth(i);

    const priceText = await product.locator('.price').textContent();

    const price = Number(priceText?.replace(/[^0-9.]/g, ""));

    expect(price).toBeLessThanOrEqual(maxPriceNum);

  }

});

Points from the video, in order:

1. maxPriceNum is declared at the start of this step, before it is used in the wait and in the final check. It holds the number 25, converted from the string "$25".

2. The products locator and the loop are the same pattern as the search step. This time we read the price in the .price element instead of the title.

3. The regular expression /[^0-9.]/g removes everything that is not a digit or a decimal point.

   - [ ] is a set of characters.

   - ^ at the start of the set means "not these".

   - 0-9 and . are the digits and the decimal point.

   - g means replace every match, not only the first one.

   So "$15.00" becomes "15.00", and Number() turns it into 15.

4. expect(price).toBeLessThanOrEqual(maxPriceNum) has no await because price is already a plain number, so there is nothing to wait for.

Full code files:

- As built in the video: https://github.com/anuradha-learn/playwright-learn-phase-1/blob/main/tests/section_05_refactoringtests/improve_journey.spec.ts

- Finished version, with small cleanups in the later steps, from the Phase 2 starter: https://github.com/anuradha-learn/phase2-starter-framework/blob/main/tests/checkout/checkout.journey.spec.ts

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.

What happened during the run? Console is not enough at scale.