In this section, we’ll build a production-ready Playwright automation framework and explain how each folder contributes to the overall architecture. This is the type of framework commonly used in enterprise applications and discussed in senior SDET interviews.
Step 1: Enterprise Framework Folder Structure
Playwright-Framework
│
├── .github/
│ └── workflows/
│ playwright.yml
│
├── pages/
│ LoginPage.ts
│ DashboardPage.ts
│ ProductPage.ts
│ CartPage.ts
│ CheckoutPage.ts
│
├── workflows/
│ LoginWorkflow.ts
│ CheckoutWorkflow.ts
│
├── fixtures/
│ baseFixture.ts
│ loginFixture.ts
│
├── utils/
│ Logger.ts
│ WaitUtility.ts
│ JsonUtility.ts
│ RandomData.ts
│ ScreenshotUtility.ts
│ Environment.ts
│
├── api/
│ CustomerAPI.ts
│ OrderAPI.ts
│
├── test-data/
│ login.json
│ checkout.json
│ products.json
│
├── constants/
│ URL.ts
│ Messages.ts
│ Timeout.ts
│
├── tests/
│ login.spec.ts
│ checkout.spec.ts
│ orders.spec.ts
│
├── reports/
├── screenshots/
├── traces/
├── videos/
│
├── playwright.config.ts
├── global-setup.ts
├── global-teardown.ts
├── package.json
└── README.mdStep 2: Responsibilities of Each Folder
pages/
Contains only page-related logic.
Example:
LoginPage
DashboardPage
CheckoutPage
PaymentPageA page object should:
- Store page locators
- Expose page actions
- Optionally expose page-specific validations
A page object should not:
- Read Excel files
- Generate random data
- Call unrelated APIs
- Contain business workflows spanning multiple pages
workflows/
Many beginners place all business logic inside page objects.
Instead, create workflow classes.
Example:
Login Workflow
↓
Open Login Page
↓
Enter Username
↓
Enter Password
↓
Click Login
↓
Verify DashboardThis keeps page objects small and reusable.
Examples:
LoginWorkflow
CheckoutWorkflow
OrderWorkflow
PaymentWorkflowfixtures/
Provides reusable setup.
Examples:
Browser Fixture
Login Fixture
API Fixture
Database FixtureAvoid creating browser instances manually in every test.
utils/
Contains reusable helper classes.
Examples:
Date Utility
Random Data
Logger
Encryption
Screenshot Utility
Download Utility
Upload Utility
PDF UtilityUtilities should remain generic and independent of specific pages.
api/
Store API helper classes separately from UI automation.
Example:
Customer API
Order API
Product API
Payment APIThis separation allows UI and API automation to evolve independently.
constants/
Avoid hardcoding values.
Examples:
Application URL
Messages
Timeout
Roles
Endpointstest-data/
Contains:
JSON
CSV
Excel
YAML
XMLAvoid storing test data inside test files.
Step 3: Workflow Layer
Enterprise frameworks often include a workflow (or business layer).
Architecture:
Test
↓
Workflow
↓
Page Objects
↓
PlaywrightExample
Instead of
Test
↓
Login Page
↓
Dashboard Page
↓
Cart Page
↓
Checkout PageUse
Test
↓
Checkout Workflow
↓
All Page ObjectsBenefits:
- Cleaner tests
- Less duplication
- Easier maintenance
Step 4: Layered Architecture
Tests
│
▼
Business Workflows
│
▼
Page Objects
│
▼
Utilities
│
▼
Playwright API
│
▼
Browser
│
▼
Web ApplicationEach layer has a single responsibility.
Step 5: Login Workflow
Instead of repeating login steps in multiple tests:
Open Login
↓
Enter Username
↓
Enter Password
↓
Click Login
↓
Verify DashboardCreate a reusable login workflow.
Advantages:
- Centralized login logic
- Easy updates
- Cleaner test cases
Step 6: Checkout Workflow
A checkout workflow might include:
Login
↓
Search Product
↓
Open Product
↓
Add to Cart
↓
Checkout
↓
Payment
↓
Order ConfirmationThis represents one business process composed of multiple page objects.
Step 7: API + UI Integration
Many enterprise projects create data through APIs before validating it in the UI.
Example:
API
Create Customer
↓
API
Create Product
↓
API
Generate Order
↓
UI
Search Order
↓
Verify StatusAdvantages:
- Faster setup
- Less UI dependency
- More stable tests
Step 8: Data Cleanup Strategy
Automation should avoid leaving unnecessary test data behind.
Typical cleanup:
Create User
↓
Execute Test
↓
Delete UserOr
Create Order
↓
Execute Test
↓
Cancel/Delete OrderCleanup can be handled:
- After each test
- After all tests
- Through scheduled database jobs (depending on the environment)
Step 9: Reusable Components
Good frameworks maximize reuse.
Reusable examples:
Login
Logout
Navigation
Calendar Selection
Dropdown Selection
Table Reader
File Upload
File DownloadAvoid copying the same logic into multiple page objects.
Step 10: Configuration Strategy
Separate configurations by environment.
Example:
Development
↓
QA
↓
UAT
↓
ProductionEach environment should define:
- Base URL
- API URL
- Credentials (prefer secure secrets management)
- Timeouts
- Feature flags (if applicable)
Step 11: Secure Credential Management
Never commit credentials to source control.
Use:
- Environment variables
- Secret managers
- CI/CD secrets
- Vault solutions (for enterprise environments)
Avoid:
admin
password123inside source files.
Step 11: Logging Architecture
Recommended logging flow:
Test Starts
↓
Log Browser Launch
↓
Log Navigation
↓
Log User Actions
↓
Log Validations
↓
Log Result
↓
Log Browser CloseKeep logs informative but concise.
Step 12: Screenshot Strategy
Capture screenshots:
- On failure
- Before destructive actions (optional)
- During debugging (optional)
Avoid capturing screenshots after every step in normal execution.
Step 13: Trace Strategy
Capture traces when:
- A test fails
- Debugging intermittent failures
- Investigating complex synchronization issues
Trace Viewer provides:
- Timeline
- DOM snapshots
- Network activity
- Console messages
- User actions
Step 14: Parallel Testing Strategy
Example:
Worker 1
Authentication
--------------------
Worker 2
Orders
--------------------
Worker 3
Payments
--------------------
Worker 4
ReportsEnsure:
- No shared state
- Independent test data
- Separate browser contexts
Step 15: Cross-Browser Strategy
Recommended execution:
Chromium
↓
Firefox
↓
WebKitRun smoke tests on all browsers and reserve full regression for the browsers required by your project.
Step 16: Continuous Integration Flow
Developer Commit
↓
Pull Request
↓
Code Review
↓
Build
↓
Install Dependencies
↓
Install Browsers
↓
Run Lint
↓
Run Unit Tests (if applicable)
↓
Run Smoke Automation
↓
Run Regression
↓
Generate Report
↓
Publish Artifacts
↓
Notify TeamStep 17: Pull Request Checklist
Before creating a PR:
- Code builds successfully
- All tests pass
- ESLint passes
- Prettier formatting applied
- No hardcoded values
- No static waits
- No duplicate methods
- Meaningful commit messages
- Updated documentation (if required)
Step 18: Versioning Strategy
Example:
Version 1.0
↓
Version 1.1
↓
Version 1.2
↓
Version 2.0Tag framework releases to simplify rollback and traceability.
Step19: Recommended NPM Scripts
Typical scripts include:
test
test:smoke
test:regression
test:headed
test:chrome
test:firefox
test:webkit
report
lint
formatThese provide a consistent way to execute different suites.
Step 20: Enterprise Coding Guidelines
Follow these principles:
Single Responsibility Principle
Each class should have one responsibility.
Open/Closed Principle
Design classes so they can be extended without modifying existing behavior wherever practical.
DRY (Don’t Repeat Yourself)
Move repeated logic into reusable methods or workflows.
KISS (Keep It Simple, Stupid)
Prefer simple, readable solutions over unnecessary complexity.
YAGNI (You Aren’t Gonna Need It)
Don’t implement features before they are actually required.
Step 21: Enterprise Framework Maturity Model
Beginner Framework
- Tests
- Page Objects
Intermediate Framework
- Fixtures
- Utilities
- Reporting
- Environment support
Advanced Framework
- Business workflows
- API integration
- Parallel execution
- CI/CD
- Authentication reuse
- Robust logging
- Cross-browser support
Enterprise Framework
- Scalable architecture
- Secure configuration management
- API + UI hybrid testing
- Containerized execution
- Cloud execution
- Comprehensive reporting
- Test analytics
- Quality gates in CI/CD
Senior Playwright Interview Questions & Answers
1. Why would you introduce a Workflow Layer?
Answer:
A workflow layer encapsulates complete business processes that span multiple pages. This keeps page objects focused on page interactions while making test cases shorter, more readable, and easier to maintain.
2. What is the difference between a Page Object and a Workflow?
Answer:
A Page Object models a single page by exposing its locators and actions.
A Workflow coordinates multiple page objects to accomplish a business process such as placing an order or completing user registration.
3. Why shouldn’t business logic be placed inside page objects?
Answer:
Business workflows often involve multiple pages. Keeping them in page objects creates oversized classes, increases coupling, and makes reuse difficult. Separating workflows improves maintainability and follows the Single Responsibility Principle.
4. How do you organize a framework for thousands of test cases?
Answer:
I organize it into layers (tests, workflows, page objects, utilities, API helpers, fixtures), group tests by feature, externalize configuration and test data, enable parallel execution, use authentication reuse, and integrate reporting and CI/CD.
5. How do you reduce execution time in Playwright?
Answer:
- Execute tests in parallel.
- Reuse authenticated sessions with
storageState. - Create test data through APIs instead of the UI where appropriate.
- Categorize suites into smoke and regression.
- Avoid unnecessary browser launches and redundant setup.
- Remove fixed waits.
6. How do you handle flaky tests?
Answer:
I investigate the root cause rather than relying on retries. Common improvements include using stable locators, waiting on application state instead of time, isolating test data, improving cleanup, and reviewing application synchronization issues.
7. What qualities define a production-ready Playwright framework?
Answer:
A production-ready framework has a clean layered architecture, reusable fixtures, focused page objects, workflow abstraction, secure configuration management, reliable reporting, logging, authentication reuse, CI/CD integration, parallel execution, cross-browser support, coding standards, and comprehensive