34. Portfolio Building

your-playwright-framework/

├── .github/workflows/playwright.yml

├── pages/

├── tests/

├── utils/

├── config/

├── conftest.py

├── pytest.ini

├── requirements.txt

├── README.md

└── docs/

└── architecture.md

Pointers: A recruiter or hiring manager typically skims a repo for under a minute before deciding whether to look closer — a clean, familiar structure (matching the enterprise-grade layout from Chapter 29) signals competence immediately, before they've read a single line of actual test code.

A strong README answers, in order: what this project demonstrates, how to run it, and why it's built the way it is — not just "how to run tests."

A full-stack UI + API test automation framework built with Playwright and pytest,

demonstrating Page Object Model architecture, CI/CD integration, and

combined UI/API validation.

- Page Object Model with a shared base page

- Auth session reuse via storage_state (fast, no repeated logins)

- Combined UI + API testing for full-stack validation

- GitHub Actions CI pipeline with HTML reporting

- Data-driven tests via pytest parametrize

# Playwright + Python Test Automation Framework

See `docs/architecture.md` for folder structure and design decisions.

Pointers: Explicitly naming the patterns demonstrated (POM, session reuse, CI integration) in the README does real work — it's often the first and only place a time-pressed reviewer looks to judge whether you understand the "why," not just the "how."

## Architecture

A 2–3 minute screen recording showing: the suite running in the terminal, a quick look at the folder structure, and maybe the HTML/Allure report it produces.

Pointers: This is a low-effort, high-impact addition — most candidate repos don't include one, so it's a genuine differentiator, and it lets a reviewer "see it work" without needing to clone and set the project up themselves.