Video Summary - มาเริ่มต้นลอง Playwright กันน

Summary: Technological Concepts & Playwright Tutorial

Purpose of the video: An introduction and hands-on guide to automation testing, with emphasis on end-to-end (E2E) testing and how Playwright helps automate browser-based testing “like the user”.
Testing pyramid review: Mentions the Software Testing Pyramid concept:
- More unit tests at the bottom (largest number),
- Fewer integration tests in the middle,
- Least E2E tests at the top (fewer, but typically more expensive and higher-impact).
E2E testing characteristics (cost/complexity):
- E2E tests take longer and can be costly when issues occur.
- Automation is presented as a way to reduce repeated manual work.

Playwright (“Play” / “Paylight”) as a Browser Automation Library

The tool is positioned as a modern browser testing framework (browser automation).

Key capabilities discussed:

Cross-browser support (Chromium/Firefox/WebKit-style browsers mentioned).
Ability to run tests and generate reports (reports are browser-viewable).
Multiple languages supported:
- JavaScript/TypeScript mentioned
- Python also noted
Ability to run tests in parallel (described as a newer tool context versus older tooling).

Comparison Concepts (Selenium vs. Playwright)

Selenium issues mentioned

Requires installing and managing drivers (per-browser components).
Setup can feel complicated/chaotic.

Playwright strengths mentioned

More convenient setup.
Easier execution across multiple browsers.
Faster experimentation and a smoother developer experience.

Tutorial: Setting Up a Playwright Project (Node/JavaScript + NPM)

Steps covered:

Create a project folder and run npm init
Install Playwright (using current install commands with common package manager variants)
Create test folder structure (e.g., test/ and example spec files)
Use a configuration file (Playwright config) as the starting point for commands and test discovery
Run tests via npx playwright test (and generate reports)

How it works:

The test runner reads spec files under the configured test directory.
The test command executes tests matching configuration patterns.

Tutorial: Writing the First Test (Spec Structure)

Playwright test basics shown:

test(): defines a test case (name + function/body)
page.goto(): navigation
expect(): assertions to verify UI state

Example behavior:

Open a page (example site like pay.de used as a stand-in).
Verify the page title contains an expected value.

Also includes:

A failing test example demonstrating how Playwright reports mismatches.

Debugging and Running Modes

Headless mode (“Head R mode”):
- Browser runs without a visible UI.
Headed mode (“Head mode”):
- Browser UI appears briefly/for debugging.

Waiting/observability concepts:

delay / waiting behavior to observe what happens.
Timeout/wait approach to handle dynamic loading and asynchronous behavior.

Locators: Selecting Elements Reliably

Focus on locator strategies:

Locator UI / auto suggestion flow (the video repeatedly uses an inspector-style workflow).
Recommendation for more stable selectors such as data-testid to avoid brittle CSS selectors.

Topics covered:

CSS selector concepts, then Playwright-style locators.
Locator query patterns:
- getBy... style queries for accessibility/semantics.
Locator ambiguity:
- If multiple elements match, the test fails until a more specific locator is used.
- Suggest using more precise strategies (label/role/text-based) when duplicates exist.

Playwright Inspector (Major Workflow Feature)

How the Inspector helps generate code:

Open the inspector.
Hover/select elements on the page.
Automatically produce locator + action code.

Inspector framed as a key productivity tool for building locators and assertions.

Example App Tests: Form Submission (Register) with Success/Failure

Tests run against a local dev server (host/port like 5173 mentioned).

Includes:

Happy path:
- Fill registration form
- Submit
- Assert success text appears
Fail path:
- Submit invalid data
- Assert validation error messages exist

Emphasis:

Use assertions to verify UI text and validation state.
Reports help reveal which step failed.

Screenshots and Visual Artifacts in Reports

Demonstrates:

Taking screenshots on failure or at configured times.
Using Playwright config options to store screenshots/videos with reports.

Also mentions:

Screenshot comparison as a foundation for visual testing later.

Additional E2E Scenarios: Login Automation Patterns

Direct login test
- Fill credentials
- Verify successful navigation/text
Preserving browser state via storage state
- Save authentication state into a JSON file (cookies/storage)
- Reuse it to avoid repeating login steps for later tests

Synchronization strategies:

waitUntil / load-state equivalents (DOM content loaded vs “network idle”-style waiting).

SSO/MFA caveat:

SSO often triggers MFA, making automation tricky.
Suggests leaving room for MFA or using special approaches for test accounts.

Global Setup / Storage State for Faster, Isolated Runs

Introduces Global Setup:

Runs once to create storage state (if missing).
Allows subsequent test runs to reuse it.

Mentions config layering:

Global config vs project-level config (e.g., separate projects for logged-in vs guest, authenticated vs unauthenticated tests).

Project Splitting to Isolate Scenarios and Control Execution

Uses Playwright projects to run subsets of tests:

Separate projects for logged-in vs guest cases
Separate handling for different test directories/files

Explains:

testMatch patterns determine which tests run in each project.

Trace / Video Recording and Test Visualization

Describes “Trace” / “view test”:

Replay and inspect each step visually over time.

Video recording configuration:

Record modes such as:
- “on first retry”
- “retain on fail”
- “retain on all fail” (some subtitle names were partially garbled)

Video output:

Appears in reports when enabled and under certain run outcomes.

Performance Test / Visual Test Categories

The video categorizes testing into:

Happy/Standard functional tests
Problem tests (invalid inputs / missing requirements / validation)
Performance tests (measuring durations with timing assertions)
Visual tests
- Screenshot snapshots and pixel comparisons
- Commands like toHaveScreenshot and snapshot matching strategies

Visual Regression Testing Workflow (Snapshot Approach)

Demonstrates:

Taking baseline screenshots on the first run.
Comparing subsequent runs against stored baselines.
Ensuring viewport consistency:
- Same viewport and aspect ratio to avoid false diffs.
A mismatch scenario showing pixel-diff-style results.

AI-Assisted Testing via MCP (Conceptual + Tooling Integration)

Introduces MCP (Model Context Protocol) conceptually:

An integration approach for AI-to-machine communication.

Shows an approach:

Install/configure Playwright-related MCP inside an AI coding tool (Cursor mentioned).
Use AI to generate browser-interaction code automatically.