Q5 of 17 · Framework design
What is a recommended folder structure for a Playwright or Selenium test framework?
Framework designMidframework-designfolder-structurearchitecturebest-practices
Short answer
Short answer: Separate concerns into: pages/ (Page Objects), tests/ (specs), fixtures/ or utils/ (helpers and shared setup), testData/ (external data), config/ (environment config), and reports/. Each layer should have a single responsibility.
Detail
Playwright TypeScript — recommended structure:
/
├── pages/ ← Page Object classes
│ ├── BasePage.ts
│ ├── LoginPage.ts
│ └── CheckoutPage.ts
├── tests/ ← Test specs, grouped by feature
│ ├── auth/
│ │ └── login.spec.ts
│ └── checkout/
│ └── checkout.spec.ts
├── fixtures/ ← Playwright fixtures (custom test() extensions)
│ └── testFixtures.ts
├── helpers/ ← Shared utilities (db helpers, API clients, date utils)
│ ├── dbHelper.ts
│ └── apiClient.ts
├── testData/ ← External test data (JSON, CSV)
│ └── users.json
├── config/ ← Environment-specific config
│ ├── env.ts
│ └── playwright.config.ts
├── reports/ ← Generated by CI, gitignored
└── package.json
Selenium Java — common structure:
src/
test/
java/
pages/
stepdefs/ ← if BDD
utils/
base/ ← BaseTest, BaseConfig
listeners/ ← TestNG listeners for reporting
resources/
testData/
config/
config.properties
features/ ← if BDD
Principles:
- Tests should import from pages/ and utils/, never from other test files
- Config reads environment variables or a .env file — no hardcoded URLs in test code
- Reports directory is gitignored but preserved in CI artifacts
- Feature-grouping under tests/ is better than type-grouping (no "all positive tests in one folder")
// WHAT INTERVIEWERS LOOK FOR
At least five meaningful directories with single-responsibility rationale. No hardcoded config in tests. Feature-based vs type-based grouping distinction.