DEV Community: Manivannan

The Complete Automation Testing Guide 2026: CI/CD, Frameworks, Mobile & Performance

Manivannan — Sat, 11 Apr 2026 03:44:55 +0000

The Complete Automation Testing Guide 2026: CI/CD, Frameworks, Mobile & Performance

Published: April 2026 | Read Time: ~30 min | Level: Beginner to Advanced

Introduction

Automation testing is no longer optional — it's the backbone of every high-velocity software team. In this comprehensive guide, we cover the four pillars of modern automation testing:

CI/CD Pipeline Testing — Automate your quality gates
Test Framework Comparison — Picking the right tool for the job
Mobile Automation Testing — Test across devices at scale
Performance & Load Testing — Ensure your system holds under pressure

Whether you're a QA engineer, a developer wearing a testing hat, or an engineering lead designing a test strategy, this guide has something for you.

Part 1: CI/CD Pipeline Testing
Part 2: Test Framework Comparison
Part 3: Mobile Automation Testing
Part 4: Performance & Load Testing
Building a Unified Test Strategy
Best Practices & Anti-Patterns
Conclusion

Part 1: CI/CD Pipeline Testing

What Is CI/CD Pipeline Testing?

CI/CD pipeline testing embeds automated quality checks directly into your delivery workflow. Every code push, pull request, or merge triggers a sequence of tests — catching bugs before they ever reach production.

Developer Push → Build → Unit Tests → Integration Tests → E2E Tests → Deploy to Staging → Smoke Tests → Deploy to Production

The Testing Pyramid in CI/CD

         /\
        /  \       ← E2E Tests (few, slow, high confidence)
       /----\
      /      \     ← Integration Tests (moderate)
     /--------\
    /          \   ← Unit Tests (many, fast, cheap)
   /____________\

Rule of thumb:

70% Unit Tests
20% Integration Tests
10% E2E / Smoke Tests

Setting Up Testing in GitHub Actions

Full Pipeline Example

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'

jobs:
  lint:
    name: Lint & Type Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check

  unit-tests:
    name: Unit Tests
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run test:unit -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

  integration-tests:
    name: Integration Tests
    runs-on: ubuntu-latest
    needs: unit-tests
    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
      redis:
        image: redis:7
        options: >-
          --health-cmd "redis-cli ping"
          --health-interval 10s
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:testpass@localhost:5432/testdb
          REDIS_URL: redis://localhost:6379

  e2e-tests:
    name: E2E Tests (Shard ${{ matrix.shard }}/${{ matrix.total }})
    runs-on: ubuntu-latest
    needs: integration-tests
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]
        total: [4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test --shard=${{ matrix.shard }}/${{ matrix.total }}
        env:
          BASE_URL: ${{ secrets.STAGING_URL }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: e2e-results-shard-${{ matrix.shard }}
          path: playwright-report/

  deploy:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: e2e-tests
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: echo "Deploying to staging..."

Quality Gates: Fail Fast, Fail Loud

- name: Check Coverage
  run: |
    COVERAGE=$(cat coverage/coverage-summary.json | jq '.total.lines.pct')
    if (( $(echo "$COVERAGE < 80" | bc -l) )); then
      echo "❌ Coverage $COVERAGE% is below 80% threshold"
      exit 1
    fi
    echo "✅ Coverage: $COVERAGE%"

Pipeline Testing Best Practices

Practice	Why It Matters
Cache dependencies	Cuts CI time by 50–70%
Parallelize test runs	Reduces feedback loop
Fail fast on lint errors	Catch cheap bugs first
Enforce coverage thresholds	Prevent regression
Use matrix builds	Test across environments
Store artifacts on failure	Easier debugging

Part 2: Test Framework Comparison

The Landscape in 2026

Choosing the right testing framework can make or break your automation strategy.

Frontend / E2E Framework Comparison

Feature	Playwright	Cypress	Selenium WebDriver	WebdriverIO
Language support	JS/TS/Python/Java/C#	JS/TS	All major languages	JS/TS
Browser support	Chromium, Firefox, WebKit	Chrome, Firefox, Edge	All browsers	All browsers
API testing	✅ Built-in	❌	❌	✅ via plugin
Auto-waiting	✅ Smart	✅ Smart	❌ Manual	✅ Smart
Parallel execution	✅ Native	⚠️ Paid (Cloud)	✅ Grid	✅ Native
Mobile testing	✅ Emulation	❌	✅ Appium	✅ Appium
Network mocking	✅	✅	❌	✅
Learning curve	Medium	Low	High	Medium

When to Use Each

Use Playwright when:

You need cross-browser testing including Safari (WebKit)
API + UI testing in one framework is a priority
You need robust parallel execution without extra cost

Use Cypress when:

Your team is just starting with automation
You primarily test React/Vue/Angular SPAs
Developer experience and debugging matter most

Use Selenium when:

You need maximum browser/platform coverage
Your organization has legacy Selenium infrastructure
You need Java or C# as your primary language

Backend / API Testing Frameworks

Framework	Language	Best For
Pytest + httpx	Python	Python backends
Jest + Supertest	JS/TS	Node.js backends
Playwright APIContext	JS/TS	Full-stack JS teams
RestAssured	Java	Java/Spring backends
Postman/Newman	Any	Teams preferring GUI

Pytest Example

# tests/test_users_api.py
import pytest
import httpx

BASE_URL = "https://api.yourapp.com"

@pytest.fixture(scope="session")
def auth_token():
    response = httpx.post(f"{BASE_URL}/auth/login", json={
        "email": "test@example.com",
        "password": "TestPass123!"
    })
    assert response.status_code == 200
    return response.json()["token"]

@pytest.fixture
def client(auth_token):
    headers = {"Authorization": f"Bearer {auth_token}"}
    return httpx.Client(base_url=BASE_URL, headers=headers)

class TestUsersAPI:
    def test_get_all_users(self, client):
        response = client.get("/users")
        assert response.status_code == 200
        assert isinstance(response.json(), list)

    @pytest.mark.parametrize("user_id,expected_status", [
        (1, 200),
        (9999, 404),
        (-1, 400),
    ])
    def test_get_user_by_id(self, client, user_id, expected_status):
        response = client.get(f"/users/{user_id}")
        assert response.status_code == expected_status

Part 3: Mobile Automation Testing

Why Mobile Automation Is Different

Mobile testing presents unique challenges:

Device fragmentation — Thousands of Android devices + multiple iOS versions
Gestures — Swipe, pinch, long-press, shake
Network conditions — 3G, 4G, offline scenarios
Platform-specific UI — Native iOS vs Android components
Permissions — Camera, location, notifications

Framework Comparison

Framework	Platform	Language	Best For
Appium	iOS + Android	Any	Cross-platform native
Detox	iOS + Android	JS/TS	React Native apps
XCUITest	iOS only	Swift/ObjC	Native iOS apps
Espresso	Android only	Java/Kotlin	Native Android apps
Maestro	iOS + Android	YAML	Simple flows, fast setup

Appium + WebdriverIO Example

// wdio.conf.ts
export const config: WebdriverIO.Config = {
  services: ['appium'],
  capabilities: [
    {
      platformName: 'Android',
      'appium:deviceName': 'Pixel_7_API_34',
      'appium:platformVersion': '14.0',
      'appium:app': './apps/myapp.apk',
      'appium:automationName': 'UiAutomator2',
    },
    {
      platformName: 'iOS',
      'appium:deviceName': 'iPhone 15',
      'appium:platformVersion': '17.2',
      'appium:app': './apps/myapp.app',
      'appium:automationName': 'XCUITest',
    },
  ],
};

// tests/mobile/login.spec.ts
describe('Mobile Login Flow', () => {
  it('should login with valid credentials', async () => {
    await $('~email-input').setValue('user@example.com');
    await $('~password-input').setValue('Password123!');
    await $('~login-button').click();
    await expect($('~welcome-heading')).toBeDisplayed();
  });

  it('should handle swipe gestures', async () => {
    const screen = await browser.getWindowRect();
    await browser.touchAction([
      { action: 'press', x: screen.width * 0.8, y: screen.height * 0.5 },
      { action: 'moveTo', x: screen.width * 0.2, y: screen.height * 0.5 },
      { action: 'release' },
    ]);
    await expect($('~onboarding-step-2')).toBeDisplayed();
  });

  it('should handle device rotation', async () => {
    await browser.setOrientation('LANDSCAPE');
    await expect($('~landscape-layout')).toBeDisplayed();
    await browser.setOrientation('PORTRAIT');
  });
});

Detox for React Native

// e2e/login.test.js
describe('Login Screen', () => {
  beforeAll(async () => { await device.launchApp(); });
  beforeEach(async () => { await device.reloadReactNative(); });

  it('should login successfully', async () => {
    await element(by.id('email-input')).typeText('user@example.com');
    await element(by.id('password-input')).typeText('Password123!');
    await element(by.id('login-button')).tap();
    await expect(element(by.id('home-screen'))).toBeVisible();
  });

  it('should scroll to bottom of long list', async () => {
    await element(by.id('scrollable-list')).scroll(500, 'down');
    await expect(element(by.id('last-item'))).toBeVisible();
  });
});

Part 4: Performance & Load Testing

Types of Performance Tests

Test Type	Purpose	Tool
Load Test	Verify behavior under expected load	k6, JMeter, Locust
Stress Test	Find the breaking point	k6, Gatling
Spike Test	Handle sudden traffic surges	k6, Artillery
Soak Test	Check for memory leaks over time	k6, Locust
Frontend Perf	Measure Core Web Vitals	Lighthouse

k6: Modern Load Testing

// load-tests/api-load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate, Trend } from 'k6/metrics';

const errorRate = new Rate('error_rate');

export const options = {
  stages: [
    { duration: '1m', target: 50 },
    { duration: '3m', target: 50 },
    { duration: '1m', target: 100 },
    { duration: '3m', target: 100 },
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const params = {
    headers: {
      'Authorization': `Bearer ${__ENV.API_TOKEN}`,
      'Content-Type': 'application/json',
    },
  };

  const listRes = http.get('https://api.yourapp.com/users', params);
  check(listRes, {
    'status is 200': (r) => r.status === 200,
    'has users': (r) => JSON.parse(r.body).length > 0,
  });
  errorRate.add(listRes.status !== 200);

  sleep(1);

  const createRes = http.post('https://api.yourapp.com/users', JSON.stringify({
    name: `Test User ${Date.now()}`,
    email: `test${Date.now()}@example.com`,
  }), params);
  check(createRes, { 'created': (r) => r.status === 201 });

  sleep(2);
}

Locust: Python-Based Load Testing

# locustfile.py
from locust import HttpUser, task, between
import random

class APIUser(HttpUser):
    wait_time = between(1, 3)

    def on_start(self):
        resp = self.client.post("/auth/login", json={
            "email": "test@example.com",
            "password": "TestPass123!"
        })
        self.token = resp.json().get("token")
        self.client.headers.update({"Authorization": f"Bearer {self.token}"})

    @task(3)
    def get_users(self):
        with self.client.get("/users", catch_response=True) as response:
            if response.status_code == 200:
                response.success()
            else:
                response.failure(f"Got {response.status_code}")

    @task(1)
    def create_user(self):
        self.client.post("/users", json={
            "name": f"Load Test User {random.randint(1000, 9999)}",
            "email": f"lt{random.randint(1000, 9999)}@test.com"
        })

    @task(2)
    def get_single_user(self):
        self.client.get(f"/users/{random.randint(1, 100)}", name="/users/[id]")

Frontend Performance with Playwright + Lighthouse

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage meets Core Web Vitals', async ({ page }) => {
  await page.goto('/');

  const lcp = await page.evaluate(() => new Promise((resolve) => {
    new PerformanceObserver((list) => {
      const entries = list.getEntries();
      resolve(entries[entries.length - 1].startTime);
    }).observe({ entryTypes: ['largest-contentful-paint'] });
    setTimeout(() => resolve(0), 5000);
  }));

  expect(lcp as number).toBeLessThan(2500); // LCP < 2.5s
});

test('no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Performance Thresholds Reference

Metric	Good	Needs Work	Poor
Response Time (p95)	< 200ms	200–500ms	> 500ms
Error Rate	< 0.1%	0.1–1%	> 1%
LCP	< 2.5s	2.5–4s	> 4s
FID	< 100ms	100–300ms	> 300ms
CLS	< 0.1	0.1–0.25	> 0.25

Building a Unified Test Strategy

Recommended Tool Stack by Team Size

Small Team (1–5 engineers)

Unit: Vitest or Jest
API: Playwright APIContext
E2E: Playwright
Performance: k6 (basic load tests)
CI: GitHub Actions

Medium Team (5–20 engineers)

Unit: Vitest + coverage reporting
API: Playwright + contract tests (Pact)
E2E: Playwright with Page Object Model
Mobile: Detox (React Native) or Appium
Performance: k6 + Grafana dashboards

Large Team (20+ engineers)

Unit: Vitest / pytest (per service)
API: Per-service contract testing (Pact)
E2E: Playwright (web) + WebdriverIO (mobile)
Mobile: BrowserStack / Sauce Labs device farm
Performance: k6 Cloud / Grafana k6
Reporting: Allure / TestRail

Best Practices & Anti-Patterns

✅ DO This

Follow the test pyramid — More unit tests, fewer E2E tests
Use data-driven testing — Parametrize scenarios to maximize coverage
Clean up test data — Always leave the system in a clean state
Test accessibility — Automate a11y checks with axe-core
Version control your tests — Tests live alongside feature code
Monitor test flakiness — Track and fix unstable tests immediately
Use semantic selectors — getByRole, getByLabel over fragile CSS paths
Set performance budgets — Fail CI if performance degrades

❌ Avoid These Anti-Patterns

Anti-Pattern	Problem	Solution
Hard-coded waits (`sleep(5000)`)	Slow and flaky	Use smart waits
Testing internal implementation	Brittle tests	Test observable behavior
Shared mutable test state	Random failures	Isolate each test
Ignoring flaky tests	Tech debt builds	Fix or quarantine
100% coverage goal	Wrong incentive	Focus on meaningful coverage
No mobile testing	Missed regressions	Add device testing to pipeline
Hardcoded credentials	Security risk	Use secrets management

Conclusion

Building a robust automation testing strategy means thinking across all four pillars:

CI/CD Pipeline Testing ensures quality gates fire on every commit, catching regressions before they reach users
Choosing the Right Framework saves months of pain — pick the tool that matches your stack, team size, and goals
Mobile Automation is no longer optional; billions of users are on mobile-first devices
Performance Testing closes the gap between "it works" and "it works at scale"

The teams that ship confidently aren't the ones that test more — they're the ones that test smarter. A well-architected automation suite becomes a force multiplier, freeing developers to move fast without breaking things.

Start small. Automate the pain points first. Iterate.

Resources

Happy Testing! 🚀

Full Stack Automation Testing with Playwright: The Complete Guide

Manivannan — Sat, 11 Apr 2026 03:25:05 +0000

Full Stack Automation Testing with Playwright: The Complete Guide

Published: April 2026 | Author: Automation Engineer | Read Time: ~20 min

Introduction

Playwright has rapidly become one of the most powerful automation testing frameworks in the industry. Originally built by Microsoft, it supports Chromium, Firefox, and WebKit out of the box, and covers everything from lightning-fast unit tests to complex end-to-end (E2E) flows — and even API testing. In this blog, we'll walk through a full-stack automation strategy using Playwright across all testing layers.

Whether you're building a testing suite from scratch or migrating from Selenium or Cypress, this guide will help you architect a robust, maintainable automation framework.

Why Playwright?
Installation & Project Setup
Unit & Integration Testing with Playwright
API Testing with Playwright
UI & End-to-End Testing
Page Object Model (POM)
Test Data Management
CI/CD Integration
Reporting & Debugging
Best Practices
Conclusion

Why Playwright?

Before diving into code, let's understand why Playwright stands out:

Feature	Playwright	Cypress	Selenium
Multi-browser support	✅ Chromium, Firefox, WebKit	⚠️ Chrome, Firefox (limited)	✅ All
API Testing built-in	✅ Yes	❌ No	❌ No
Auto-wait mechanism	✅ Smart waits	✅ Smart waits	❌ Manual waits
Parallel execution	✅ Native	⚠️ Dashboard (paid)	⚠️ Grid required
Network interception	✅ Yes	✅ Yes	❌ Limited
Headless mode	✅ Yes	✅ Yes	✅ Yes
TypeScript support	✅ First-class	✅ Yes	⚠️ Partial
Mobile emulation	✅ Yes	❌ No	❌ Limited

Playwright's ability to handle API, UI, and integration testing in one framework makes it an ideal choice for full-stack teams.

Installation & Project Setup

Prerequisites

Node.js v18 or above
npm or yarn

Step 1: Initialize a New Project

mkdir playwright-fullstack-tests
cd playwright-fullstack-tests
npm init -y

Step 2: Install Playwright

npm init playwright@latest

This will prompt you to:

Choose TypeScript or JavaScript (recommend TypeScript)
Set the test directory (default: tests/)
Add a GitHub Actions workflow (optional but recommended)
Install Playwright browsers

Step 3: Recommended Folder Structure

playwright-fullstack-tests/
├── tests/
│   ├── unit/
│   │   └── utils.spec.ts
│   ├── integration/
│   │   └── auth.spec.ts
│   ├── api/
│   │   └── users-api.spec.ts
│   └── e2e/
│       └── checkout.spec.ts
├── pages/                    # Page Object Models
│   ├── LoginPage.ts
│   └── DashboardPage.ts
├── fixtures/                 # Custom fixtures
│   └── base.fixture.ts
├── test-data/                # Test data files
│   └── users.json
├── utils/                    # Helper utilities
│   └── api-helper.ts
├── playwright.config.ts
├── .env
└── package.json

Step 4: Configure `playwright.config.ts`

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

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: [
    ['html', { outputFolder: 'playwright-report' }],
    ['list'],
    ['junit', { outputFile: 'results.xml' }],
  ],
  use: {
    baseURL: process.env.BASE_URL || 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
    {
      name: 'Mobile Chrome',
      use: { ...devices['Pixel 5'] },
    },
    {
      name: 'api',
      testDir: './tests/api',
      use: {
        baseURL: process.env.API_BASE_URL || 'https://api.yourapp.com',
      },
    },
  ],
});

Unit & Integration Testing with Playwright

While Playwright is predominantly known for browser automation, it integrates seamlessly with component testing (via @playwright/experimental-ct-react for React) and works alongside Jest/Vitest for pure unit tests.

Integration Test Example: Authentication Flow

// tests/integration/auth.spec.ts
import { test, expect, request } from '@playwright/test';

test.describe('Authentication Integration', () => {
  let authToken: string;

  test.beforeAll(async () => {
    const apiContext = await request.newContext({
      baseURL: 'https://api.yourapp.com',
    });

    const response = await apiContext.post('/auth/login', {
      data: {
        username: 'testuser@example.com',
        password: 'SecurePass123!',
      },
    });

    expect(response.ok()).toBeTruthy();
    const body = await response.json();
    authToken = body.token;
  });

  test('should access protected endpoint with valid token', async ({ request }) => {
    const response = await request.get('/api/profile', {
      headers: { Authorization: `Bearer ${authToken}` },
    });
    expect(response.status()).toBe(200);
    const data = await response.json();
    expect(data).toHaveProperty('email');
  });

  test('should reject request without token', async ({ request }) => {
    const response = await request.get('/api/profile');
    expect(response.status()).toBe(401);
  });
});

API Testing with Playwright

Playwright's APIRequestContext is a first-class citizen for REST and GraphQL testing. No need for external libraries like Supertest or Axios in your test suite.

REST API Testing

// tests/api/users-api.spec.ts
import { test, expect } from '@playwright/test';

const BASE_URL = 'https://jsonplaceholder.typicode.com';

test.describe('Users API', () => {

  test('GET /users - should return list of users', async ({ request }) => {
    const response = await request.get(`${BASE_URL}/users`);
    expect(response.status()).toBe(200);
    const users = await response.json();
    expect(Array.isArray(users)).toBeTruthy();
    expect(users[0]).toMatchObject({
      id: expect.any(Number),
      name: expect.any(String),
      email: expect.any(String),
    });
  });

  test('POST /users - should create a new user', async ({ request }) => {
    const newUser = { name: 'John Playwright', username: 'jplaywright', email: 'john@playwright.dev' };
    const response = await request.post(`${BASE_URL}/users`, { data: newUser });
    expect(response.status()).toBe(201);
    const created = await response.json();
    expect(created.name).toBe(newUser.name);
  });

  test('PUT /users/:id - should update user', async ({ request }) => {
    const response = await request.put(`${BASE_URL}/users/1`, { data: { name: 'Updated Name' } });
    expect(response.status()).toBe(200);
    const body = await response.json();
    expect(body.name).toBe('Updated Name');
  });

  test('DELETE /users/:id - should delete user', async ({ request }) => {
    const response = await request.delete(`${BASE_URL}/users/1`);
    expect(response.status()).toBe(200);
  });

});

GraphQL API Testing

// tests/api/graphql.spec.ts
import { test, expect } from '@playwright/test';

test.describe('GraphQL API Tests', () => {

  test('should fetch user via GraphQL query', async ({ request }) => {
    const query = `
      query GetUser($id: ID!) {
        user(id: $id) { id name email posts { title } }
      }
    `;

    const response = await request.post('https://graphql.yourapp.com/graphql', {
      data: { query, variables: { id: '1' } },
      headers: { 'Content-Type': 'application/json' },
    });

    expect(response.ok()).toBeTruthy();
    const { data, errors } = await response.json();
    expect(errors).toBeUndefined();
    expect(data.user).toHaveProperty('name');
  });

});

UI & End-to-End Testing

This is where Playwright truly shines. Smart auto-waits, network interception, and multi-browser support make complex user flows reliable and fast.

Basic UI Test

// tests/e2e/login.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Login Flow', () => {

  test('should login successfully with valid credentials', async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill('user@example.com');
    await page.getByLabel('Password').fill('Password123!');
    await page.getByRole('button', { name: 'Sign In' }).click();
    await expect(page).toHaveURL('/dashboard');
    await expect(page.getByRole('heading', { name: 'Welcome' })).toBeVisible();
  });

  test('should show error with invalid credentials', async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill('wrong@example.com');
    await page.getByLabel('Password').fill('WrongPass');
    await page.getByRole('button', { name: 'Sign In' }).click();
    await expect(page.getByText('Invalid email or password')).toBeVisible();
  });

});

Network Interception & Mocking

test('should display mocked user data on dashboard', async ({ page }) => {
  await page.route('**/api/user/profile', async (route) => {
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ name: 'Test User', email: 'test@example.com', plan: 'Pro' }),
    });
  });

  await page.goto('/dashboard');
  await expect(page.getByText('Test User')).toBeVisible();
  await expect(page.getByText('Pro')).toBeVisible();
});

File Upload Testing

test('should upload a profile picture', async ({ page }) => {
  await page.goto('/settings/profile');
  const fileChooserPromise = page.waitForEvent('filechooser');
  await page.getByText('Upload Photo').click();
  const fileChooser = await fileChooserPromise;
  await fileChooser.setFiles('./test-data/avatar.png');
  await expect(page.getByText('Photo uploaded successfully')).toBeVisible();
});

Mobile Emulation

import { test, expect, devices } from '@playwright/test';

test.use({ ...devices['iPhone 13'] });

test('should render mobile menu correctly', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('button', { name: 'Menu' }).click();
  await expect(page.getByRole('navigation')).toBeVisible();
});

Page Object Model (POM)

The Page Object Model keeps your tests clean and maintainable. Each page gets its own class encapsulating selectors and actions.

Creating a Page Object

// pages/LoginPage.ts
import { Page, Locator, expect } from '@playwright/test';

export class LoginPage {
  readonly page: Page;
  readonly emailInput: Locator;
  readonly passwordInput: Locator;
  readonly signInButton: Locator;
  readonly errorMessage: Locator;

  constructor(page: Page) {
    this.page = page;
    this.emailInput = page.getByLabel('Email');
    this.passwordInput = page.getByLabel('Password');
    this.signInButton = page.getByRole('button', { name: 'Sign In' });
    this.errorMessage = page.getByTestId('login-error');
  }

  async goto() { await this.page.goto('/login'); }

  async login(email: string, password: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.signInButton.click();
  }

  async expectError(message: string) {
    await expect(this.errorMessage).toContainText(message);
  }
}

Using POM in Tests

import { test, expect } from '@playwright/test';
import { LoginPage } from '../../pages/LoginPage';

test.describe('Login with POM', () => {
  let loginPage: LoginPage;

  test.beforeEach(async ({ page }) => {
    loginPage = new LoginPage(page);
    await loginPage.goto();
  });

  test('valid login redirects to dashboard', async ({ page }) => {
    await loginPage.login('user@example.com', 'Password123!');
    await expect(page).toHaveURL('/dashboard');
  });

  test('invalid login shows error', async () => {
    await loginPage.login('bad@email.com', 'wrongpass');
    await loginPage.expectError('Invalid email or password');
  });
});

Test Data Management

Using JSON Fixtures

{
  "validUser": {
    "email": "testuser@example.com",
    "password": "ValidPass123!",
    "name": "Test User"
  },
  "adminUser": {
    "email": "admin@example.com",
    "password": "AdminPass456!",
    "name": "Admin User"
  }
}

Custom Fixtures with Playwright

// fixtures/base.fixture.ts
import { test as base } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';
import users from '../test-data/users.json';

type MyFixtures = {
  loginPage: LoginPage;
  authenticatedPage: { page: any; token: string };
};

export const test = base.extend<MyFixtures>({
  loginPage: async ({ page }, use) => {
    const loginPage = new LoginPage(page);
    await loginPage.goto();
    await use(loginPage);
  },

  authenticatedPage: async ({ page, request }, use) => {
    const response = await request.post('/auth/login', { data: users.validUser });
    const { token } = await response.json();
    await page.addInitScript((authToken) => {
      localStorage.setItem('authToken', authToken);
    }, token);
    await page.goto('/dashboard');
    await use({ page, token });
  },
});

export { expect } from '@playwright/test';

CI/CD Integration

GitHub Actions Workflow

name: Playwright Tests

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test --shard=${{ matrix.shard }}/4
        env:
          BASE_URL: ${{ secrets.STAGING_URL }}
          API_BASE_URL: ${{ secrets.API_URL }}
      - name: Upload test report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report-shard-${{ matrix.shard }}
          path: playwright-report/
          retention-days: 30

Reporting & Debugging

Built-in HTML Reporter

npx playwright test
npx playwright show-report

Trace Viewer for Debugging

npx playwright test --trace on
npx playwright show-trace test-results/trace.zip

Debug Mode (Step-by-step)

npx playwright test --debug
npx playwright test tests/e2e/login.spec.ts --debug

Codegen (Auto-generate tests)

npx playwright codegen https://yourapp.com

Best Practices

✅ DO's

Use semantic locators — Prefer getByRole, getByLabel, getByTestId over CSS/XPath selectors
Avoid hard-coded waits — Never use page.waitForTimeout(3000). Use waitForSelector, waitForResponse, or rely on Playwright's auto-wait
Keep tests independent — Each test should set up its own state and not rely on others
Use fixtures for shared setup/teardown logic
Parametrize tests with test.each for data-driven scenarios
Tag your tests with @smoke, @regression, @api for selective runs
Mock external services to avoid flakiness from third-party dependencies
Run in parallel — Playwright supports full parallelism; use shards for CI

❌ DON'Ts

Don't use page.pause() in committed code — only use it during local debugging
Don't test implementation details — test from the user's perspective
Don't ignore flaky tests — investigate and fix them, don't just retry
Don't commit .env files with real credentials
Don't use generic locators like page.locator('div:nth-child(3)') — these break easily

Example: Data-Driven Test with `test.each`

const testCases = [
  { email: '', password: 'pass', error: 'Email is required' },
  { email: 'notanemail', password: 'pass', error: 'Invalid email format' },
  { email: 'user@ex.com', password: '', error: 'Password is required' },
];

testCases.forEach(({ email, password, error }) => {
  test(`shows "${error}" for email="${email}" password="${password}"`, async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(email);
    await page.getByLabel('Password').fill(password);
    await page.getByRole('button', { name: 'Sign In' }).click();
    await expect(page.getByText(error)).toBeVisible();
  });
});

Conclusion

Playwright is more than just a UI automation tool — it's a complete full-stack testing platform. By combining API testing, integration testing, and end-to-end UI tests under one framework, you can:

Reduce tool sprawl (no need for separate Postman, Supertest, and Selenium setups)
Share authentication state across test layers
Ship faster with parallel execution and smart retries
Debug confidently with trace viewer and screenshots

Whether you're a solo developer or part of a large QA team, adopting Playwright across your full test stack will dramatically improve your test coverage, reliability, and developer experience.

Resources

Happy Testing! 🎭

DEV Community: Manivannan

The Complete Automation Testing Guide 2026: CI/CD, Frameworks, Mobile & Performance

The Complete Automation Testing Guide 2026: CI/CD, Frameworks, Mobile & Performance

Introduction

Table of Contents

Part 1: CI/CD Pipeline Testing

What Is CI/CD Pipeline Testing?

The Testing Pyramid in CI/CD

Setting Up Testing in GitHub Actions

Full Pipeline Example

Quality Gates: Fail Fast, Fail Loud

Pipeline Testing Best Practices

Part 2: Test Framework Comparison

The Landscape in 2026

Frontend / E2E Framework Comparison

When to Use Each

Backend / API Testing Frameworks

Pytest Example

Part 3: Mobile Automation Testing

Why Mobile Automation Is Different

Framework Comparison

Appium + WebdriverIO Example

Detox for React Native

Part 4: Performance & Load Testing

Types of Performance Tests

k6: Modern Load Testing

Locust: Python-Based Load Testing

Frontend Performance with Playwright + Lighthouse

Performance Thresholds Reference

Building a Unified Test Strategy

Recommended Tool Stack by Team Size

Small Team (1–5 engineers)

Medium Team (5–20 engineers)

Large Team (20+ engineers)

Best Practices & Anti-Patterns

✅ DO This

❌ Avoid These Anti-Patterns

Conclusion

Resources

Full Stack Automation Testing with Playwright: The Complete Guide

Full Stack Automation Testing with Playwright: The Complete Guide

Introduction

Table of Contents

Why Playwright?

Installation & Project Setup

Prerequisites

Step 1: Initialize a New Project

Step 2: Install Playwright

Step 3: Recommended Folder Structure

Step 4: Configure playwright.config.ts

Unit & Integration Testing with Playwright

Integration Test Example: Authentication Flow

API Testing with Playwright

REST API Testing

GraphQL API Testing

UI & End-to-End Testing

Basic UI Test

Network Interception & Mocking

File Upload Testing

Mobile Emulation

Page Object Model (POM)

Creating a Page Object

Using POM in Tests

Test Data Management

Using JSON Fixtures

Custom Fixtures with Playwright

CI/CD Integration

GitHub Actions Workflow

Reporting & Debugging

Built-in HTML Reporter

Trace Viewer for Debugging

Debug Mode (Step-by-step)

Codegen (Auto-generate tests)

Best Practices

✅ DO's

❌ DON'Ts

Example: Data-Driven Test with test.each

Conclusion

Resources

Step 4: Configure `playwright.config.ts`

Example: Data-Driven Test with `test.each`