DEV Community: Shefali R

Everything You Need for API Automation (A Complete Blueprint)

Shefali R — Sat, 15 Aug 2026 21:44:51 +0000

Setting up an API automation framework requires aligning business goals, developer specifications, infrastructure, and core testing strategies.

Here is a comprehensive requirement checklist and workflow to ensure complete coverage across every stage of your API automation setup.

1. Requirements from Client / Business Owner

Before writing code, define what needs to be tested:

Business requirements (BRD) & user stories / use cases
Expected API behavior & acceptance criteria (success & failure cases)
Priority APIs (critical vs optional pathing)
Performance expectations (SLA, response time)
API versioning policy (backward compatibility expectations)
Security & compliance requirements (data privacy, PII handling)

2. Technical Details from Developers

Understand how the APIs operate:

API Documentation: Swagger / OpenAPI specifications
Endpoints: Base URL + specific paths
HTTP Methods: GET, POST, PUT, DELETE, PATCH
Request Details: Headers, query params, request body (JSON/XML)
Response Details: Expected status codes (200, 201, 400, 401, 403, 404, 500) and response schema structures
Authentication: OAuth, JWT, API keys, or Basic Auth
Error Handling: Error codes & error messages
API Contracts: Consumer-driven contract definitions (e.g., using Pact)
Rate Limits & Throttling: Maximum request limits and wait strategies
Downstream Dependencies: Dependent APIs required for mock/stub planning

3. Infrastructure & Environment Setup

Coordinate with the Application Owner or Infra Team for execution requirements:

Environment URLs: Dev, QA, UAT, and Prod environments
Access Control: VPN access, API gateway setups, credentials
Test Data Strategy:
- Valid, invalid, edge case, and boundary value datasets
- Data seeding scripts for pre-test setup
- Data teardown/cleanup scripts for post-test cleanup
- Data isolation per environment
Database Access: Direct access for validating API output directly against DB records
Mocking/Stubbing: Availability of tools like WireMock or MSW for dependent APIs
Secrets Management: Environment variables (.env, secret managers) to avoid hardcoding sensitive tokens

4. Recommended Tooling Stack

Category	Recommended Tools
Manual Testing (First Step)	Postman (validate requests/responses, export collections to Newman)
Automation Tools	Playwright (JavaScript), RestAssured (Java), PyTest + Requests (Python), Karate
Performance Testing	k6, JMeter, Gatling
Security Testing	OWASP ZAP, Burp Suite
Contract Testing	Pact
Mocking / Stubbing	WireMock, MSW
CI/CD Integration	Jenkins, GitHub Actions, GitLab CI
Reporting	Allure Report, HTML Reporter, Extent Reports

5. Automation Framework Setup

Ensure your test automation codebase includes:

Data-driven, reusable design patterns
Reusable request utility and helper functions
Automatic authentication handling (token refreshes, session management)
Schema validation engines (JSON Schema / Ajv)
Comprehensive test suites covering:
- Positive test coverage (happy paths)
- Negative test coverage (missing fields, invalid data types, boundary values, malformed payloads, unauthorized access)
Multi-layer assertion strategy (status code + body structure + response headers + schema)
Pre-test data seeding and post-test data cleanup
Centralized logging and error reporting
Dynamic configuration management across environments
Code review guidelines prior to merging automation scripts

6. Pro Tips for API Automation

Manual First: Always validate endpoints manually in Postman before writing automated scripts.
Ensure API Stability: Wait until the endpoints are stable before investing time in script creation.
Keep Secrets Secret: Never hardcode credentials—manage access via environment variables or secret store managers.
Clean Up After Execution: Implement automated teardown routines to clean up test-created data.
Assert Schemas: Run schema validation on every response, not just status code checks.
Unified Frameworks: If using tools like Playwright, leverage the built-in API request context to combine API and UI tests within a single framework.

7. The Complete API Execution Workflow

Get API Details (Swagger/Docs)
       ↓
Manual Validation in Postman
       ↓
Schema & Contract Validation Setup
       ↓
Test Data Seeding
       ↓
Automate Scenarios (Positive + Negative + Edge Cases)
       ↓
Schema Assertions on Response
       ↓
Code Review & Approval
       ↓
CI/CD Pipeline Integration (Trigger on Build)
       ↓
Test Reporting (Allure / HTML Reports)
       ↓
Post-Test Data Cleanup (Teardown)
       ↓
Production Monitoring & Alerts

Must-Have Quick Verification Checklist

Swagger / API documentation received
Postman collections created & verified
Environment credentials and VPN access ready
Valid/Invalid test data seeded
Mock servers running for external dependencies
Test reporting integrated with CI/CD pipeline
Automated teardown configured

What tools are you currently using in your API automation stack? Let's discuss in the comments below!

Playwright + Cucumber Code Review Checklist: A Senior QA Guide to Reliable CI Test Suites

Shefali R — Sat, 15 Aug 2026 20:54:36 +0000

Building an enterprise test automation framework is one thing; keeping it reliable, maintainable, and fast in CI over time is another.

To prevent test rot, flakiness, and architectural drift, code reviews need to evaluate more than just standard syntax. They must enforce design boundaries, state isolation, and robust synchronization strategies.

Here is the complete Code Review Checklist we use for our Playwright + JavaScript + Cucumber BDD suites. Feel free to adopt or adapt it for your team's workflow!

Playwright JavaScript Framework — Code Review Checklist

Use this checklist during pull request reviews to keep tests reliable, maintainable, secure, and CI-friendly.

Scope

New Playwright test scenarios
Updated Cucumber feature files and step definitions
Changes to page objects, hooks, utilities, config, and test data
Reporting, retry, CI, and environment-related automation changes

Review Checklist

1. Test Intent and Coverage

Does the change clearly cover a real business workflow or acceptance criterion?
Is the scenario scoped to a single behavior instead of combining multiple unrelated validations?
Are positive, negative, and edge-case paths considered where appropriate?
Are feature names, scenario names, and tags meaningful and consistent?
Is there any duplication with an existing scenario that should be reused or refactored?

2. Feature File Quality (Cucumber)

Are Given, When, and Then steps written from the user's perspective?
Are scenarios concise, readable, and free of implementation details?
Are tags applied correctly for execution targeting (e.g., @smoke, @admin, @performer, @approver)?
Is Background used only for simple shared preconditions?
Are hardcoded credentials, URLs, IDs, or sensitive values avoided in feature files?

3. Step Definition Quality

Are step definitions thin and delegated to page objects or utilities?
Are duplicate or overly similar step definitions avoided?
Is shared scenario state stored on the Cucumber World object (this) instead of globals?
Are step definitions readable and reusable across scenarios?
Do step definitions avoid embedding large selectors, raw waits, or excessive business logic?

4. Page Object Design

Are UI interactions encapsulated in the correct page object under page-objects/?
Are selectors centralized in the page object instead of duplicated across steps?
Are page object methods named by user intent (e.g., createGroup, approveTask, searchQuery)?
Are page objects focused on actions and state access rather than test assertions?
If a page object became too large, should it be split into smaller components or helper classes?

5. Selector Strategy

Are selectors stable and intention-revealing?
Are data-qa, data-test, data-testid, or semantic Playwright locators preferred?
Are fragile selectors such as positional XPath, generated classes, or deep CSS chains avoided?
If a stable selector was not available, is the fallback rationale documented?
Are selector updates aligned with SELECTORS.md?

6. Assertions and Validation

Are assertions using Playwright's expect with web-first behavior?
Do assertions verify outcomes that matter to the user or workflow?
Are assertions placed in the appropriate layer rather than hidden inside unrelated helpers?
Are weak checks avoided, such as validating only that a page loaded without confirming expected data or state?
Where useful, do assertion messages or attachments help future debugging?

7. Waiting and Synchronization

Does the code rely on Playwright auto-waiting wherever possible?
Are explicit waits tied to real signals like element state, navigation, or API responses?
Are arbitrary sleeps such as waitForTimeout() avoided?
If network-dependent behavior exists, does the code wait on the relevant response or UI state change?
Could any race condition appear under CI speed or parallel execution?

8. Test Isolation and State Management

Can the scenario run independently and in any order?
Is test setup and teardown handled through hooks where appropriate?
Are browser context, page, storage state, and created records isolated per scenario?
Is cleanup handled for created users, groups, files, or seeded data when needed?
Does the change introduce hidden dependencies on previously executed tests?

9. Test Data Handling

Is test data externalized to test-data/, factories, or utilities where appropriate?
Are unique identifiers used to avoid collisions in shared environments?
Are hardcoded dates, names, or IDs avoided unless they are intentionally fixed test fixtures?
Is seeded data documented and compatible with the current environment?
Are data generation and cleanup steps deterministic and maintainable?

10. Configuration and Environment Safety

Are environment-specific values sourced from config.js or environment variables?
Are .env values kept out of committed code and documentation examples unless intentionally sanitized?
Does the change behave safely across local, QA, and CI environments?
Are timeouts, retries, browser settings, and base URLs configurable rather than hardcoded?
Is the documentation updated if the new change adds or alters configuration requirements?

11. Authentication and Secrets

Are credentials sourced only from environment variables or approved secret stores?
Are login flows reusable and abstracted where appropriate?
Are session files, tokens, or auth-state artifacts excluded from source control if sensitive?
Are sensitive values omitted from logs, screenshots, attachments, and console output?
Is the implementation aligned with SECRETS.md and ENV_SETUP.md?

12. Flakiness, Retries, and Reliability

Does the change reduce or increase flakiness risk?
Are retries treated as a safety net rather than the primary fix?
If a flaky area is touched, was the root cause addressed instead of masking the problem?
Is the scenario safe to run under current workers and retry settings?
Is the change consistent with FLAKINESS.md?

13. Logging, Debugging, and Failure Diagnostics

Will a future failure be easy to diagnose from logs, screenshots, traces, and reports?
Are screenshots, traces, or attachments captured at the right level when failures occur?
Does the code use structured logging utilities instead of noisy console.log statements?
Are debug artifacts meaningful and free of sensitive data?
If the reviewer had to debug this in CI, would the report provide enough context?

14. Code Quality and Maintainability

Is the code easy to read, with clear function and variable names?
Are functions small and focused on one responsibility?
Is duplication avoided through helpers, shared steps, or utility methods?
Is the module style consistent with the codebase conventions?
Are unused imports, dead code, commented-out blocks, and temporary debugging code removed?

15. Hooks, Utilities, and Shared Framework Code

If setup/hooks.js or shared utilities changed, have downstream impacts been considered?
Are hooks minimal, predictable, and safe for all tagged scenarios they affect?
Do shared utilities remain generic enough for reuse?
Could the change unintentionally affect unrelated modules like Admin, Performer, Approver?
If framework behavior changed, should related docs or runbooks be updated?

16. Parallelism and CI Compatibility

Will the change behave correctly when tests run in parallel or rerun on failure?
Are file paths, downloads, screenshots, and artifacts unique per test where needed?
Does the change assume a local-only environment or headed execution?
Is the scenario suitable for CI headless mode?
Are run tags and suite grouping still appropriate for smoke vs broader regression?

17. Reporting and Observability

Are Allure and other reporting outputs still generated correctly?
Are important artifacts attached for failures without creating excessive noise?
Does the change preserve report readability and trend usefulness?
If new metadata, labels, or attachments were added, are they helpful and consistent?
Are report-related updates aligned with current scripts and CI expectations?

18. Security, Compliance, and Governance

Does the change avoid exposing confidential business data in code, fixtures, or reports?
If AI-assisted code was introduced, does it receive human review per AI_GOVERNANCE.md?
Are compliance-sensitive workflows documented clearly enough for audit or review if needed?
Does the change follow team expectations captured in DoD.md?

Reviewer Quick Reference

Before hitting Approve, ask yourself:

Would this still be understandable to a new automation engineer in three months?
Would this remain reliable in CI under retry and parallel execution?
Would a failure provide enough evidence to debug quickly?
Did this change add unnecessary complexity to the framework?
Is the root cause solved, or is the PR only hiding symptoms?

How do you handle PR reviews for your automation suites? Let me know in the comments!

Automate Email Verification in Playwright using Microsoft Graph API & TypeScript

Shefali R — Sat, 15 Aug 2026 20:43:54 +0000

Automating end-to-end flows like user registration, password resets, or OTP verifications often hits a wall when dealing with emails. Automating UI login for webmail providers like Gmail or Outlook is flaky and frequently blocked by 2FA or CAPTCHAs.

Using Microsoft Graph API with an Azure App Registration (Client Credentials Flow) lets you fetch target user inbox messages programmatically in your Playwright tests without any UI interaction.

1. Prerequisites & Azure Setup

Before writing test code, configure your Azure Entra ID (formerly Azure AD):

Register an App: Go to Azure Portal > App registrations > New registration.
Set Permissions: Navigate to API permissions > Add a permission > Microsoft Graph > Application permissions.
Select Mail.Read (or Mail.ReadWrite if you plan to delete emails post-test).
Grant Admin Consent: Click Grant admin consent for [Your Org].
Create Credentials: Go to Certificates & secrets > New client secret. Store the secret securely.

Collect the following environment variables:

AZURE_TENANT_ID
AZURE_CLIENT_ID
AZURE_CLIENT_SECRET

2. Install Required Dependencies

Install the Azure Identity SDK and Microsoft Graph Client:

npm install @azure/identity @microsoft/microsoft-graph-client

3. Build the Graph Email Service

Create a dedicated helper service (graphService.ts) to manage authentication, inbox polling, and token extraction.

import { ClientSecretCredential } from '@azure/identity';
import { Client } from '@microsoft/microsoft-graph-client';
import { TokenCredentialAuthenticationProvider } from '@microsoft/microsoft-graph-client/authProviders/azureTokenCredentials';

export class GraphService {
  private graphClient: Client;

  constructor() {
    const tenantId = process.env.AZURE_TENANT_ID!;
    const clientId = process.env.AZURE_CLIENT_ID!;
    const clientSecret = process.env.AZURE_CLIENT_SECRET!;

    const credential = new ClientSecretCredential(tenantId, clientId, clientSecret);
    const authProvider = new TokenCredentialAuthenticationProvider(credential, {
      scopes: ['[https://graph.microsoft.com/.default](https://graph.microsoft.com/.default)'],
    });

    this.graphClient = Client.initWithMiddleware({ authProvider });
  }

  /**
   * Polls the inbox for an email matching specific subject criteria within a timeout.
   */
  async getLatestEmail(targetEmail: string, subjectContains: string, timeoutMs = 30000): Promise<string> {
    const startTime = Date.now();

    while (Date.now() - startTime < timeoutMs) {
      const response = await this.graphClient
        .api(/users/${targetEmail}/messages)
        .filter(contains(subject, '${subjectContains}'))
        .select('subject,body,receivedDateTime')
        .orderby('receivedDateTime desc')
        .top(1)
        .get();

      if (response.value && response.value.length > 0) {
        return response.value[0].body.content;
      }

      // Wait 3 seconds before polling again
      await new Promise((resolve) => setTimeout(resolve, 3000));
    }

    throw new Error(Email with subject containing "${subjectContains}" was not received within ${timeoutMs}ms.);
  }

  /**
   * Helper to extract links or OTP codes using regular expressions.
   */
  extractPattern(htmlContent: string, pattern: RegExp): string {
    const match = htmlContent.match(pattern);
    if (!match) {
      throw new Error(Pattern ${pattern} not found in the email content.);
    }
    return match[1] || match[0];
  }
}

4. Integrate with Playwright Tests

Use the service directly inside your Playwright test file (emailValidation.spec.ts):

import { test, expect } from '@playwright/test';
import { GraphService } from './graphService';

test.describe('Registration & Email Verification Flow', () => {
  const graphService = new GraphService();
  const testUserEmail = 'qa-automation@yourdomain.com';

  test('User registers and verifies OTP from email', async ({ page }) => {
    // 1. Trigger signup action in web app
    await page.goto('[https://example.com/register](https://example.com/register)');
    await page.fill('#email', testUserEmail);
    await page.click('#submit-btn');

    // 2. Fetch latest email and extract 6-digit OTP
    const emailBody = await graphService.getLatestEmail(testUserEmail, 'Your Verification Code');
    const otpCode = graphService.extractPattern(emailBody, /\b\d{6}\b/);

    // 3. Complete verification on page
    await page.fill('#otp-input', otpCode);
    await page.click('#verify-btn');

    // 4. Assert successful navigation
    await expect(page.locator('#dashboard')).toBeVisible();
  });
});

Key Takeaways

No Flaky UI: API-level retrieval eliminates UI dependency for email checking.
Polling Strategy: Always implement retry loops with timeouts to account for network latency in email delivery.
Security: Limit application permissions in Azure using Application Access Policies if you need to restrict access to specific automated QA mailboxes.

Building a Custom API Testing Framework Using Playwright and TypeScript

Shefali R — Sat, 15 Aug 2026 20:08:50 +0000

1. Introduction & API Testing Strategy

While Playwright is widely known for UI automation, its built-in API request context provides a lightweight, highly efficient framework for REST API testing without needing Postman or RestAssured.

Executing API tests within Playwright allows for seamless integration tests—such as generating test data via API requests before executing end-to-end browser workflows.

2. Setting Up the Base API Request Context (playwright.config.ts)

Configure the base URL, headers, and authentication tokens globally within the configuration file:

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

export default defineConfig({
  use: {
    baseURL: '[https://api.example.com/v1](https://api.example.com/v1)',
    extraHTTPHeaders: {
      'Accept': 'application/json',
      'Content-Type': 'application/json',
      'Authorization': Bearer ${process.env.API_TOKEN || 'test-token'},
    },
  },
});

3. Writing Modular CRUD Tests (tests/api/users.spec.ts)

Leverage Playwright's request fixture to perform standard HTTP actions and assert JSON response payloads:

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

test.describe('Users API Endpoints', () => {
  let createdUserId: string;

  test('POST /users - Create new user record', async ({ request }) => {
    const response = await request.post('/users', {
      data: {
        name: 'Automation Tester',
        email: 'test.user@example.com',
        role: 'QA Engineer',
      },
    });

    expect(response.status()).toBe(201);
    const body = await response.json();
    expect(body.name).toBe('Automation Tester');
    expect(body.id).toBeTruthy();

    createdUserId = body.id;
  });

  test('GET /users/{id} - Fetch user details', async ({ request }) => {
    const response = await request.get(/users/${createdUserId});

    expect(response.ok()).toBeTruthy();
    const body = await response.json();
    expect(body.email).toBe('test.user@example.com');
  });

  test('DELETE /users/{id} - Clean up user record', async ({ request }) => {
    const response = await request.delete(/users/${createdUserId});
    expect(response.status()).toBe(204);
  });
});

4. Key Takeaways

Fast Execution: Running direct HTTP requests bypasses browser overhead, allowing hundreds of API assertions to execute in seconds.
Hybrid Testing: You can combine API requests with UI automation—for instance, using API setup calls to prime database state before executing UI test scripts.

Complete CI/CD Pipeline Integration for Automated Playwright Test Suites

Shefali R — Sat, 15 Aug 2026 20:05:06 +0000

1. Introduction & Workflow Architecture

Running end-to-end tests locally is fine for development, but automated regression testing requires a continuous integration (CI) workflow.

Executing browser automation inside isolated CI containers ensures that tests run against reproducible environments on every pull request.

+----------------+   +-----------------------+   +--------------------+
| Developer Push | --> | GitHub Actions/CI   | --> | Matrix Execution   |
| (Pull Request) |   | Pipeline Trigger      |   | (Shard 1/3...) |
+----------------+   +-----------------------+   +---------+----------+
                                                           |
                                                           v
                                                 +--------------------+
                                                 | HTML Report        |
                                                 | Artifacts          |
                                                 +--------------------+

2. Playwright Configuration (playwright.config.ts)

Configure Playwright to adjust worker threads dynamically based on whether it runs locally or inside a CI environment:

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

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI if resource-constrained, or limit worker count */
  workers: process.env.CI ? 2 : undefined,
  reporter: process.env.CI ? [['github'], ['html', { open: 'never' }]] : 'list',
  use: {
    baseURL: process.env.BASE_URL || '[https://staging.example.com](https://staging.example.com)',
    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'] },
    },
  ],
});

3. GitHub Actions Workflow Configuration (.github/workflows/playwright.yml)

This production-ready workflow installs required system dependencies, caches Node modules, runs parallel test shards, and uploads HTML execution reports as build artifacts:

name: Playwright Regression Pipeline

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

jobs:
  test:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shard: [1/3, 2/3, 3/3]
    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: 'npm'

    - name: Install dependencies
      run: npm ci

    - name: Install Playwright Browsers with dependencies
      run: npx playwright install --with-deps

    - name: Run Playwright tests (Shard ${{ matrix.shard }})
      run: npx playwright test --shard=${{ matrix.shard }}
      env:
        BASE_URL: ${{ secrets.STAGING_BASE_URL }}

    - name: Upload Test Report Artifact
      uses: actions/upload-artifact@v4
      if: ${{ !cancelled() }}
      with:
        name: playwright-report-shard-${{ strategy.job-index }}
        path: playwright-report/
        retention-days: 14

4. Key Optimization Takeaways

Parallel Sharding: Utilizing matrix strategy (--shard=1/3) splits the test suite across multiple runner virtual machines, cutting overall CI build time by up to 60%.
Artifact Storage: Standardized actions/upload-artifact@v4 configurations preserve failure traces and video recordings without bloating git history.
Environment Security: Sensitivity parameters like staging endpoints and credentials should always be injected via repository secrets (${{ secrets.STAGING_BASE_URL }}) rather than hardcoded in project settings.

Step-by-Step: Migrating a Legacy Selenium Java Suite to Modular Playwright TypeScript

Shefali R — Sat, 15 Aug 2026 19:49:35 +0000

1. Introduction & Motivation

Migrating a legacy Selenium suite isn't just about changing syntax—it's about fixing structural test flakiness and execution lag.

Legacy Selenium Java Approach

Selenium requires explicit driver management, verbose setup, and manual wait configurations:

public class LoginTest {
    WebDriver driver;

    @BeforeMethod
    public void setUp() {
        System.setProperty("webdriver.chrome.driver", "path/to/chromedriver");
        driver = new ChromeDriver();
        driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
    }

    @Test
    public void testLogin() {
        driver.get("https://app.example.com/login");
        WebElement emailInput = driver.findElement(By.id("username"));
        emailInput.sendKeys("user@example.com");

        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(5));
        WebElement submitBtn = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit-btn")));
        submitBtn.click();
    }
}

Modern Playwright TypeScript Approach

Playwright provides built-in browser contexts, automatic waiting, and clean user-visible locators out of the box:

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

test('login test', async ({ page }) => {
  await page.goto('https://app.example.com/login');
  await page.getByLabel('Username').fill('user@example.com');
  await page.getByRole('button', { name: 'Submit' }).click();
  await expect(page.getByText('Dashboard')).toBeVisible();
});

2. Core Migration Steps

1.Directory Coexistence: Run npm init playwright@latest inside your root repository alongside Maven/Gradle to allow incremental test migration.

2.Page Object Model Translation: Convert Java classes into modular TypeScript exports:

   import { Page, Locator } from '@playwright/test';

export class LoginPage {
  readonly emailInput: Locator;
  readonly submitButton: Locator;

  constructor(private readonly page: Page) {
    this.emailInput = this.page.getByLabel('Username');
    this.submitButton = this.page.getByRole('button', { name: 'Submit' });
  }

  async login(email: string) {
    await this.emailInput.fill(email);
    await this.submitButton.click();
  }
}

3.Eliminating Explicit Waits: Replace WebDriverWait logic with Playwright’s auto-waiting locators, which automatically check for visibility, actionability, and stability before executing interactions.

3. Edge Cases & Gotchas

Cross-Domain iFrames: Selenium requires explicit context switching via driver.switchTo().frame(). Playwright handles frame navigation natively using frame locators:

   const frame = page.frameLocator('#my-iframe');
   await frame.getByRole('button', { name: 'Confirm' }).click();

Cookie and Storage State Persistence: Bypass repetitive UI login steps by generating a single storageState.json during global setup and reusing it across spec files.