Day 1 - Building a Playwright API Automation Framework from Scratch
I've been meaning to build a proper API test automation framework for a while now, and I finally started today. Sharing my progress here as I go - partly to document it, partly to keep myself accountable.
π€ Why Playwright for API testing? Most people know Playwright for UI automation, but it has a solid built-in API request client as well. No need for separate tools like Rest Assured or Supertest - one framework handles both UI and API. That's what drew me to it.
π ️ Tech stack I chose:
→ Playwright Test - test runner + HTTP client
→ TypeScript - type safety and better code structure
→ Allure - for rich HTML reporting
→ dotenv - for environment variable management
π Folder structure I'm following:
Playwright_API_Framework/
├── src/
│ ├── clients/
│ │ └── baseApiClient.ts ← Base HTTP client
│ └── services/
│ ├── userService.ts ← User API operations
│ └── authService.ts ← Login / Register operations
├── tests/ ← Test files (coming next)
├── test-data/ ← Payloads and schemas (coming next)
├── fixtures/ ← Playwright fixtures (coming next)
├── playwright.config.ts ← Framework config
├── tsconfig.json ← TypeScript config
└── .env ← Environment variables
✅ What I implemented today:
1️⃣ tsconfig.json — configured TypeScript with strict mode, path aliases like @services/* and @clients/* to avoid messy relative imports
2️⃣ playwright.config.ts — set up parallel execution with 4 workers, Allure reporter, multi-environment projects (dev/staging/prod) with environment-specific base URLs loaded from .env
3️⃣ baseApiClient.ts — created a base class that wraps Playwright's request context and exposes clean get(), post(), put(), patch(), delete() methods
4️⃣ userService.ts and authService.ts — these extend BaseApiClient and expose endpoint-specific methods like getUsers(), createUser(), login() etc. This is what I would call the API Object Model - same concept as Page Object Model but for APIs.
No comments:
Post a Comment