Duration:11 Days
Format: Playwright + TypeScript, in VS Code
Before you start: Node.js, VS Code, and Git installed on your laptop.
By the end, you’ll walk away with: A GitHub repo containing a real Playwright + TypeScript framework, Page Object Model, fixtures, UI tests, API tests — built and Deploy.
Day 6-7 — Git & GitHub Basics (init, commit, push, clone, branching)
- Overview of version control and why every automation project needs it
- Step-by-step guide to Git init, commit, push, clone, and branching
- Create your own GitHub repository and push your Phase 1 test scripts to it
Day 8 — TypeScript for Testers (types, interfaces, async/await)
- Overview of TypeScript and why it's used for Playwright automation
- Step-by-step guide to types, interfaces, and async/await
- Convert one of your existing tests into clean, typed TypeScript
Day 9 — Playwright Config, Fixtures & Hooks
- Overview of playwright.config.ts and what it controls
- Step-by-step guide to setting up fixtures and hooks for reusable test setup
- Create a fixture that logs in once and reuses it across multiple tests
Day 10 — Advanced Selectors & Locators
- Overview of more advanced locator strategies beyond the Phase 1 basics
- Step-by-step guide to chaining, filtering, and handling tricky elements
- Practice: locate and interact with a genuinely tricky element on a real page
Day 11 — Page Object Model & Framework Architecture
- Overview of the Page Object Model and why real frameworks use it
- Step-by-step guide to structuring page classes and reusable actions
- Build your first page object and rewrite an earlier test to use it
Day 12 — Data-Driven Testing
- Overview of running the same test with different sets of data
- Step-by-step guide to looping tests over a data set
- Practice: turn one test into a data-driven test with 3+ data variations
Day 13 — Debugging Your Tests (trace viewer, inspector, retries, flaky tests)
- Overview of Playwright's debugging tools — trace viewer and inspector
- Step-by-step guide to reading a failed test and finding the real cause
- Practice: deliberately break a test, then find and fix it using the trace viewer
Day 14 — API Testing & BDD Framework (Theory Only)
- Overview of API testing — what is an API, why test APIs vs UI testing, HTTP methods (GET, POST, PUT, DELETE, PATCH), response validation (status codes, headers, response body structure)
- When to test API — speed, reliability, test data setup, error scenarios, and how Playwright's request object enables async/await API testing with assertions
- BDD (Behavior-Driven Development) and Cucumber.js — Given/When/Then Gherkin syntax, why BDD makes tests readable for non-technical stakeholders, how feature files and step definitions work, integration with Playwright
Day 15 — BDD Framework Implementation (Practical Only)
- Install Cucumber.js and Gherkin, set up project structure with feature files and step definitions
- Write API feature files with Given/When/Then scenarios for login, get data, create data flows
- Implement step definitions that call Playwright API methods, manage auth tokens and session reuse across scenarios
- Build complete API BDD test suite, execute tests, validate Cucumber reports
Day 16 — Overview of Network Mocking, Framework Review & What's Next
- Overview of network mocking — simulating API responses without a real server
- Full review of the framework you've built across Phase 2
- Live session: your framework works locally — here's what it takes to run automatically, and what Phase 3 covers
Where this naturally leads: This framework works — on your machine, when you run it yourself. It doesn't yet run automatically when code changes, and nothing about it is visible to a team the way a real engineering workflow is. Making that happen automatically, safely, and repeatedly is a CI/CD problem — which is what Phase 3 solves.