Putting It All Together

You have all the pieces. Now let us assemble the complete picture and walk through the final checklist that makes your test suite production-ready.

The Complete playwright.config.ts

import { defineConfig, devices } from '@playwright/test';
import dotenv from 'dotenv';
import path from 'path';

if (!process.env.CI) {
  dotenv.config({ path: path.resolve(__dirname, '.env.test') });
}

export default defineConfig({
  testDir: './specs',
  outputDir: './test-results',

  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? '50%' : undefined,

  reporter: process.env.CI
    ? [['html', { open: 'never' }], ['github'], ['list']]
    : [['html']],

  use: {
    baseURL: process.env.BASE_URL || 'https://www.testerrank.com',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'on-first-retry',
    actionTimeout: 15_000,
    navigationTimeout: 30_000,
  },

  projects: [
    {
      name: 'setup',
      testMatch: /auth\.setup\.ts/,
    },
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        storageState: '.auth/user.json',
      },
      dependencies: ['setup'],
    },
    {
      name: 'firefox',
      use: {
        ...devices['Desktop Firefox'],
        storageState: '.auth/user.json',
      },
      dependencies: ['setup'],
    },
    {
      name: 'mobile-chrome',
      use: {
        ...devices['Pixel 7'],
        storageState: '.auth/user.json',
      },
      dependencies: ['setup'],
    },
  ],
});

Production Readiness Checklist

Common Mistakes to Avoid

• Testing implementation details instead of user behavior -- do not assert on class names, internal state, or API response shapes. Assert on what the user sees.
• Sharing state between tests -- every test should start clean. Do not rely on a previous test creating data. Use fixtures and API helpers for setup.
• Ignoring flaky tests -- a flaky test that is ignored today becomes 10 ignored tests next month. Fix or quarantine them immediately.
• Over-mocking -- mock only what you must (third-party services, error states). Real API calls catch real integration bugs.
• Testing on one browser only -- at minimum, run Chromium on every PR and add Firefox/Safari in nightly regression.
• No cleanup -- if your test creates data (user, order), clean it up. Otherwise test runs pollute each other.

What Your Resume Should Say

You have now built something real. Here is how to describe it on your resume or in an interview:

"Built a production-grade E2E test suite using Playwright and TypeScript covering 28 test scenarios across authentication, product search, cart management, checkout, and visual regression. Implemented Page Object Model with base page inheritance, custom fixtures for dependency injection, storage state authentication, data-driven testing, and API mocking for edge cases. Set up a dual CI pipeline with GitHub Actions -- smoke tests on every PR (3 min) and sharded nightly regression across 3 browsers (15 min)."