Scaling Playwright Tests with Azure Cloud Browsers

Browser testing is essential for web application quality, but running tests locally or on limited CI runners creates bottlenecks as test suites grow. Azure Playwright Workspaces (formerly Microsoft Playwright Testing) provides cloud-hosted browsers that enable massive parallelization, dramatically reducing test execution time. This TypeScript SDK skill allows AI agents to configure Playwright tests to run on Azure infrastructure with integrated reporting in the Azure portal.

What This Skill Does

The azure-microsoft-playwright-testing-ts skill provides TypeScript integration for running Playwright tests on Azure-hosted browsers. It handles authentication with Azure Entra ID for secure browser access, configuration generation for test projects, parallel test execution with configurable worker counts, Azure portal integration for test result visualization, and support for both Windows and Linux browser environments.

This skill enables agents to generate service configurations that route tests to Azure browsers, authenticate test runners using DefaultAzureCredential for passwordless access, scale test execution to 20+ parallel workers without infrastructure management, publish test results to Azure portal for team visibility, and configure network exposure for testing local development servers.

The SDK supports both automatic configuration through initialization commands and manual configuration for custom scenarios. It includes an Azure reporter that uploads test results, screenshots, and traces to the portal for centralized test result management.

Getting Started

The recommended approach uses the initialization command that auto-generates configuration:

npm init @azure/playwright@latest

This creates the necessary configuration files. For manual installation:

npm install @azure/playwright --save-dev
npm install @playwright/test@^1.47 --save-dev
npm install @azure/identity --save-dev

Set the workspace URL environment variable from your Azure Playwright Workspace:

export PLAYWRIGHT_SERVICE_URL="wss://eastus.api.playwright.microsoft.com/playwrightworkspaces/{workspace-id}/browsers"

Authenticate with Azure CLI for local development:

az login

Key Features

Automatic Configuration: The createAzurePlaywrightConfig function merges your existing Playwright configuration with Azure service settings, handling browser connection endpoints, authentication credential injection, timeout configurations, and network exposure settings.

Entra ID Authentication: Use Azure Entra ID (formerly Azure Active Directory) for authentication instead of static access tokens. DefaultAzureCredential automatically discovers credentials from Azure CLI locally, managed identity in Azure environments, or service principal credentials in CI/CD pipelines.

Custom Credentials: Support for alternative credential types including ManagedIdentityCredential for Azure-hosted CI runners, ClientSecretCredential for service principal authentication, and AzureCliCredential for explicit Azure CLI authentication.

Operating System Selection: Choose between Linux and Windows browser environments. Linux is the default for cost efficiency and faster startup, while Windows may be needed for testing Windows-specific browser behaviors.

Azure Reporter: The Azure reporter uploads test results, screenshots, and traces to Azure portal, providing centralized test history, failure analysis with visual diffs, trace viewer integration for debugging, and team collaboration on test failures.

Network Exposure: Configure network exposure to enable cloud browsers to access local development servers. The setting exposes localhost addresses for testing applications running on the CI runner or developer machine.

Usage Examples

Creating a service configuration for production testing:

// playwright.service.config.ts
import { defineConfig } from "@playwright/test";
import { createAzurePlaywrightConfig, ServiceOS } from "@azure/playwright";
import { DefaultAzureCredential } from "@azure/identity";
import config from "./playwright.config";

export default defineConfig(
  config,
  createAzurePlaywrightConfig(config, {
    os: ServiceOS.LINUX,
    connectTimeout: 30000,
    exposeNetwork: "<loopback>",
    credential: new DefaultAzureCredential(),
  }),
  {
    reporter: [
      ["html", { open: "never" }],
      ["@azure/playwright/reporter"],
    ],
  }
);

Running tests with high parallelization:

npx playwright test --config=playwright.service.config.ts --workers=20

Manual browser connection for advanced scenarios:

import playwright, { test, expect, BrowserType } from "@playwright/test";
import { getConnectOptions } from "@azure/playwright";

test("custom browser connection", async ({ browserName }) => {
  const { wsEndpoint, options } = await getConnectOptions();
  const browser = await (playwright[browserName] as BrowserType)
    .connect(wsEndpoint, options);
  
  const context = await browser.newContext({
    viewport: { width: 1920, height: 1080 },
    deviceScaleFactor: 2
  });
  
  const page = await context.newPage();
  await page.goto("https://example.com");
  await expect(page).toHaveTitle(/Example/);
  
  await browser.close();
});

Best Practices

Always use Entra ID authentication with explicit credential objects rather than access tokens. Entra ID provides better security through time-limited tokens, support for managed identity in Azure environments, and integration with conditional access policies and multi-factor authentication.

Provide the credential parameter explicitly when calling createAzurePlaywrightConfig. While some examples may show implicit credential discovery, explicit credential passing ensures predictable authentication behavior and easier troubleshooting.

Enable artifacts in your Playwright configuration for effective debugging. Set trace: "on-first-retry" and video: "retain-on-failure" to capture diagnostic information for failed tests. These artifacts upload to Azure portal through the Azure reporter.

Scale workers aggressively for faster test execution. Azure provides the browser capacity, so use --workers=20 or higher based on your test suite size. More workers directly reduces total test time without infrastructure provisioning.

Choose the Azure region closest to your test targets to minimize latency. If testing production services in Europe, use a European workspace. Network latency impacts test reliability and execution time.

List the HTML reporter before the Azure reporter in configuration. This ensures local HTML reports generate even if Azure reporter fails, providing a fallback for test result visibility during development.

Configure proper timeouts for test operations. Cloud browser connections may have higher latency than local browsers. Increase default timeouts if experiencing flaky tests due to connection issues.

When to Use This Skill

Use this skill when CI/CD pipeline test execution becomes a bottleneck. If your Playwright test suite takes 30+ minutes on standard CI runners, Azure cloud browsers can reduce that to minutes through massive parallelization without infrastructure management.

It's ideal for teams with large test suites requiring frequent execution. Products with comprehensive end-to-end test coverage benefit from faster feedback loops, enabling more frequent deployments and higher confidence in release quality.

The skill is valuable when test infrastructure management overhead outweighs test value. Azure handles browser provisioning, updates, and capacity management, eliminating infrastructure maintenance while providing consistent test environments.

Use it for distributed teams needing centralized test result visibility. The Azure portal integration provides a single location for test history, failure analysis, and collaboration regardless of where tests execute.

When Not to Use This Skill

Don't use this skill for small test suites that execute quickly on standard CI runners. If your entire suite completes in under 5 minutes, the overhead of cloud browser connection may not provide meaningful benefits.

If you're testing applications that can't be accessed from Azure networks, cloud browsers won't work. Applications behind strict corporate firewalls or on-premise infrastructure without public endpoints require local browser testing.

Avoid it for tests requiring specific browser extensions or custom browser modifications. Cloud browsers provide standard browser configurations. Custom setups require local browser control.

Don't use it for unit tests or API tests that don't require browser rendering. Cloud browsers are for end-to-end UI testing. Other test types execute faster and cheaper without browser overhead.

Related Skills

• azure-mgmt-applicationinsights-dotnet - Monitor test infrastructure with Application Insights
• azure-resource-manager-playwright-dotnet - Manage Playwright workspace resources programmatically
• azure-servicebus-py - Integrate test completion notifications

Source

This skill is provided by Microsoft as part of Azure Playwright Workspaces. Learn more at the npm package page, review the migration guide for moving from the legacy package, and explore Azure Playwright Workspaces documentation for workspace setup and configuration.