Microsoft 365 Champion community break in August
August 13, 2025How Microsoft Semantic Kernel Transforms Proven Workflows into Intelligent Agents
August 13, 2025Azure 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.
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.
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-examplesdemo-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://.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://.azurewebsites.net
# Full suite (Windows CMD)
set BASE_URL=https://.azurewebsites.net && ^
npx playwright test -c playwright.config.ts –reporter=line
# Focused test
set BASE_URL=https://.azurewebsites.net && ^
npx playwright test -c playwright.config.ts tests-examplesdemo-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.