Azure App Testing centralizes functional and performance testing for your apps. With Playwright Workspaces, you can author, execute, and analyze browser tests at scale, both locally and in the cloud, with shared reporting and parallel, cloud-hosted browsers.

If you’re new to the service, start with this Overview and QuickStart. 

Azure App Testing combines Azure Load Testing and Playwright Workspaces to validate application performance and functionality at scale. Load Testing generates high-scale, multi-region traffic (including private endpoints) using JMeter or Locust, with detailed performance metrics to identify bottlenecks. Playwright Workspaces enables parallel, cross-browser/device end-to-end testing with rich insights for debugging and optimization. Together, they provide an integrated solution for stress-testing and validating applications. The following diagram shows an overview of how Azure App Testing integrates these capabilities:

Create a Playwright Workspace (portal quick tour)

• In the Azure portal, search for “Azure App Testing”, open it, and select “Create.”
• Choose “Playwright Workspaces” (use “Azure Load Testing” for performance/load).
• Provide a name, region, and subscription, then create the workspace.
• Open your Playwright Workspace to author and run tests locally or on cloud-hosted browsers, and view results in “Test runs.”

Note: A workspace lets you publish test results and artifacts and (optionally) run tests on cloud browsers for high parallelism and faster feedback.

What you’ll do in this guide

• Run Playwright locally with an auto-started dev server.
• Point tests at a deployed Azure Web App.
• Publish runs to a Playwright Workspace (and optionally fan out on cloud-hosted browsers).

Application Under Test

Sample app: Node + Express (ESM) with a minimal Todo page.

Repository (clone this first)

1) Clone the repo and install

git clone https://github.com/jvargh/azure-playwright-testing.git

cd azure-playwright-testing

npm install

# (Optional, but helpful if you haven’t used Playwright locally yet)
npx playwright install

2) App layout & behavior

Entry: ./server.js

Port: process.env.PORT || 3000 (Azure-ready)

Routes:

• GET / → simple “Welcome” page
• GET /todomvc → minimal TodoMVC-style page (localStorage-backed)

The app is intentionally tiny so you can focus on the test flow (local → Azure Web App → Workspace).

Config files you’ll use

• playwright.config.ts (base): General settings (projects, reporters). Override baseURL per run via BASE_URL.
• playwright.local.config.ts (local dev): Uses webServer to auto-start the app and targets http://localhost:3000. webServer.command runs node ./server.js.
• playwright.service.config.ts (Workspace): Adds the Azure service reporter/integration to publish runs to your workspace.

Note: The QuickStart above covers the service region endpoint and package integration for publishing and cloud browsers.

NPM scripts

• start:src → start the local server
• test:local → run locally using playwright.local.config.ts
• test:azure → run against your Azure Web App URL
• test:workspace → publish runs to your Workspace
• test:workspace:scale → same as above, but cranks up workers to scale with cloud browsers

You can always open the HTML report locally with:  npx playwright show-report

Playwright run sequences

1) Run against Local (auto server via playwright.local.config.ts)

Why: Fast dev loop—Playwright spins up http://localhost:3000  for you.

# One-shot via npm:
npm run test:local

# Under the hood (Windows CMD):
npx playwright test -c playwright.local.config.ts --reporter=line

Outcome: Starts node ./server.js, waits for http://localhost:3000, runs tests, and reuses the server on the next run.

Manual variant (start server yourself, then point BASE_URL at it):

node .\server.js
set BASE_URL=http://localhost:3000 && npx playwright test -c playwright.config.ts --reporter=line

Tip: To target a single test or title on Windows CMD:

npx playwright test -c playwright.local.config.ts tests-examples\demo-todo-app.spec.ts -g "should allow me to add todo items" --reporter=line

2) Run against your Azure Web App (base config + BASE_URL)

Prereq: Your app is deployed and reachable at the given URL.

Why: Validate the real, deployed site as no local server needed.

# One-shot NPM
set BASE_URL=https://<app>.azurewebsites.net && npm run test:azure

# Cross-platform option (no shell differences)
npm i -D cross-env
## Make changes in package.json
{
  "scripts": {
    "test:azure": "cross-env BASE_URL=$npm_config_baseurl npx playwright test -c playwright.config.ts --reporter=line"
  }
}
npm run test:azure --baseurl=https://<app>.azurewebsites.net

# Full suite (Windows CMD)
set BASE_URL=https://<azure-webapp>.azurewebsites.net && ^
npx playwright test -c playwright.config.ts --reporter=line

# Focused test
set BASE_URL=https://<azure-webapp>.azurewebsites.net && ^
npx playwright test -c playwright.config.ts tests-examples\demo-todo-app.spec.ts -g "should allow me to add todo items" --reporter=line

Outcome: Reuses your base config but targets the live app via BASE_URL.

3) Run in your Playwright Workspace (playwright.service.config.ts)

One-time per shell/session: Authenticate and set region service URL

az login

# Use the region where your workspace is created, e.g., eastus
set PLAYWRIGHT_SERVICE_URL=https://eastus.api.playwright.microsoft.com

Why: Publish results/artifacts to the Workspace (portal), and optionally run at scale on cloud-hosted browsers for higher parallelism.

# Publish (local browsers):
npm run test:workspace

# Publish at scale (cloud-hosted browsers):
npm run test:workspace:scale

# Equivalent raw command:
npx playwright test -c playwright.service.config.ts --reporter=line

Outcome: Results and artifacts appear under Test runs in the Workspace; the scaled run adds parallel workers on cloud browsers.

Tip: The QuickStart walks through setting the service region endpoint, service config file, and package integration for cloud browsers.

Troubleshooting nudges 

• BASE_URL not honored? Confirm you’re invoking the intended config (-c ...config.ts) and setting BASE_URL in the same shell.
• Workspace runs not showing up? Re-run az login, verify PLAYWRIGHT_SERVICE_URL matches your workspace region, and check role access if needed.
• Runs taking too long? Increase workers only where it helps—optimal parallelism is app-specific and benefits from experimentation.

Conclusion

You now have a clear, repeatable path to run the same Playwright tests locally with a self-started server, against your deployed Azure Web App, and in Playwright Workspaces with centralized reporting and optional cloud scale.

Use this flow during development (local), before releases (staging/prod Web App), and continuously (Workspace + CI) to keep feedback fast and reliable.