Try it: Claude Code and Playwright on the UI5 Shopping Cart

Reading about an agent is no substitute for watching one work. In this lesson you'll point Claude Code and Playwright at SAP's public SAPUI5 Shopping Cart demo, a real UI5 app with a product catalog, a cart and a checkout wizard, served from the UI5 demo kit with no login. You'll see what goes right, then deliberately make it brittle. Use only this public demo. Never point an agent's browser at CMQ or any company system from a personal setup.

Before you start

Install Node.js (an LTS release) and Claude Code, and create an empty folder for the exercise.
In that folder run npm init playwright@latest and accept the defaults. This creates a Playwright Test project with a config file and an example test.
Add the Playwright MCP server so Claude Code can drive a browser: claude mcp add playwright npx @playwright/mcp@latest. Its README describes how it works: the agent reads structured accessibility snapshots of the page, not screenshots.
Copy the Playwright rules from lesson 2's CLAUDE.md into a CLAUDE.md in the folder: role and text locators first, no IDs starting with __, no fixed waits, a fresh browser context per test.

Run the exercise

Start claude in the folder and ask it to explore: "Open the cart demo with the Playwright browser. Pick any category and any product whose status is Available, add it to the cart, open the cart, and list each control you used with its role and accessible name."
Ask it to write the test: "Write tests/cart.spec.ts. Check that the product you added appears in the cart and that Proceed is enabled. Use role and text locators only, no fixed waits. Run it three times and summarize the results."
Read the test line by line before you accept it. Check every locator against what you saw in the browser, and look for hidden waits or hard-coded product names.
Open the trace for any run with npx playwright show-trace and step through the DOM snapshots and network calls.
Optional: run npx playwright init-agents --loop=claude to try Playwright's own planner, generator and healer agents in Claude Code.

Claude Code explores through the Playwright MCP server, writes a test file, and hands it to a person who reviews and owns it.

The Sign-Off Table · thesignofftable.com/academy/sap-aiq-201

What goes right

Fast, readable first drafts. Working from accessibility snapshots, the agent tends to choose role and name locators such as the Add to Cart button, which Playwright's docs recommend over CSS and XPath.
Auto-waiting. Before each action Playwright checks that the element is visible, stable, receives events and is enabled, and its web-first assertions retry until they pass or time out.
Clean state per test. Each Playwright test gets a fresh browser context, so the cart starts empty.
Good diagnostics. The trace viewer shows each action with before and after DOM snapshots, console logs and network requests.

Example

What a reviewed test might look like

import { test, expect } from '@playwright/test';
const CART = process.env.CART_URL; // the demo URL
test('product added to cart is listed with Proceed enabled', async ({ page }) => {
  await page.goto(CART);
  await page.getByText(process.env.CATEGORY).click();
  await page.getByText(process.env.PRODUCT).first().click();
  await page.getByRole('button', { name: 'Add to Cart' }).click();
  await page.getByRole('button', { name: 'Show Shopping Cart' }).click();
  await expect(page.getByText(process.env.PRODUCT).last()).toBeVisible();
  await expect(page.getByRole('button', { name: 'Proceed' })).toBeEnabled();
});

This is an illustrative sketch, not a verified script: names come from environment variables so you choose any category and product you saw, and your locators may differ. Compare it with what Claude Code wrote.

Where it gets brittle

Area	What you saw work	What breaks it
Control IDs	Role and name locators	The Add to Cart button has no ID in its XML view, so UI5 generates one starting with `__`. An agent that falls back to IDs writes a time bomb.
Timing	Actionability checks and retrying assertions	The demo's mock server answers after 500 ms by default and accepts a `serverDelay` URL parameter. Playwright waits for elements, not for UI5 to be idle.
State	Fresh context per test	The cart is stored in browser local storage. Playwright MCP uses a persistent profile by default, so exploration sessions keep old cart items.
Data	"Pick any product"	Products are Available, Out of Stock or Discontinued; the last two open dialogs. Each regeneration may choose differently.
Output	A passing test today	Ask twice and you get two different tests. Playwright's healer may even skip a test it decides is testing broken functionality.
Upgrades	Today's UI5 rendering	The demo kit served UI5 1.153 when this course was reviewed; markup and accessibility details can change with each version.

The same six areas in the cart demo: what worked on day one, and what breaks it later.

The Sign-Off Table · thesignofftable.com/academy/sap-aiq-201

None of this means the exercise failed. A reviewed, committed test from this session is a reasonable Playwright test. The lesson is about where the effort goes next: in UI5-aware synchronization (see sap-tau-202), in test data that doesn't drift, and in a person who owns every line of code through each SAP and UI5 release.

What would you do?

The cart test Claude Code wrote passes on the engineer's laptop but fails about one run in five in the CI pipeline, on the step that checks the product appears in the cart. What should the engineer do first?

Key points

Claude Code plus Playwright MCP produces readable first drafts quickly, using role and name locators.
Playwright's auto-waiting and trace viewer are real strengths; they don't know when UI5 is idle.
Generated IDs, mock-server timing, persistent state and data variety all made the cart test brittle.
Generated code is a draft: review it, commit it, run the committed version, and assign an owner.

Before you start

Run the exercise

What goes right

Where it gets brittle

Lesson check