Use when running E2E tests, setting up the E2E environment, debugging E2E test failures, or verifying code changes work from a user's perspective. Triggers include "run E2E tests", "verify changes", "Playwright", "test setup", "E2E failures".
npx skills add https://github.com/Automattic/sensei --skill e2e-testing
Run Playwright E2E tests to verify changes work from a user's perspective — real browser, real Stripe test transactions, real WordPress site.
| Task | Command |
|------|---------|
| First-time setup | bin/setup-e2e-local.sh && pnpm run build:client && pnpm run test:e2e-setup |
| Run all tests | pnpm run test:e2e |
| Run specific test | pnpm run test:e2e tests/e2e/specs/wcpay/merchant/file.spec.ts |
| Run by name | pnpm run test:e2e -- -g "test name" |
| Run merchant tests | pnpm run test:e2e tests/e2e/specs/wcpay/merchant |
| Run shopper tests | pnpm run test:e2e tests/e2e/specs/wcpay/shopper |
| UI mode | pnpm run test:e2e-ui (open http://localhost:8077) |
| Start containers | pnpm run test:e2e-up |
| Stop containers | pnpm run test:e2e-down |
| Full reset | pnpm run test:e2e-reset |
| View report | pnpm exec playwright show-report |
pnpm install and composer install completedpnpm run up) — needed for credential detection bin/setup-e2e-local.sh
This auto-detects credentials from:
local/secrets.php) — Stripe test keyswp option get wcpay_account_data) — Stripe Account IDIt asks interactively for anything it can't find.
Options:
--server-path /path/to/transact-platform-server — override auto-detection--live — use live server mode (Jetpack tokens) instead of local--with-subscriptions — include subscription tests--help — see all options pnpm run build:client
pnpm run test:e2e-setup
This takes several minutes. It:
pnpm run test:e2e tests/e2e/specs/wcpay/merchant/merchant-admin-deposits.spec.ts
Before running pnpm run test:e2e-setup, these steps are required:
server/ and missioncontrol/ gitignored (populated via pnpm run pull). After the E2E setup clones the repo, these dirs are empty. The setup script (bin/setup-e2e-local.sh) handles this automatically, or manually: rsync -a --delete /path/to/transact-platform-server/server/ tests/e2e/deps/transact-platform-server-e2e/server/
rsync -a --delete /path/to/transact-platform-server/missioncontrol/ tests/e2e/deps/transact-platform-server-e2e/missioncontrol/
composer install after cloning: cd tests/e2e/deps/wcp-dev-tools-e2e && composer install --no-dev --no-interaction
git clone --depth=1 "$WCP_DEV_TOOLS_REPO" tests/e2e/deps/wcp-dev-tools-e2e
cd tests/e2e/deps/wcp-dev-tools-e2e && composer install --no-dev
docker ps then docker stop <container>host.docker.internal not found (Linux): Create tests/e2e/docker-compose.override.yml: services:
playwright:
environment:
- BASE_URL=http://localhost:8084
WCP_DEV_TOOLS_REPO in local.env points to a valid git repo or local pathserver/ dir in the E2E clone. Run rsync step above.composer install in tests/e2e/deps/wcp-dev-tools-e2e/.bin/setup-e2e-local.sh (auto-creates and onboards), or complete setup in Stripe Dashboard.pnpm run test:e2e-reset first for a clean start.# 1. Docker running?
docker info > /dev/null 2>&1 || echo "Start Docker first"
# 2. E2E containers up?
docker ps --format '{{.Names}}' | grep -q wcp_e2e_wordpress || pnpm run test:e2e-up
# 3. Client built with latest changes?
pnpm run build:client
After a change to merchant admin UI:
pnpm run test:e2e tests/e2e/specs/wcpay/merchant/
After a change to checkout/shopper flow:
pnpm run test:e2e tests/e2e/specs/wcpay/shopper/
After a change to a specific feature (e.g., disputes):
pnpm run test:e2e -- -g "dispute"
Run a single spec file:
pnpm run test:e2e tests/e2e/specs/wcpay/merchant/merchant-admin-disputes.spec.ts
Run block-based checkout tests only:
pnpm run test:e2e -- --grep @blocks
pnpm exec playwright show-report to open in browsertests/e2e/test-results/tests/e2e/test-results/ (open with pnpm exec playwright show-trace <trace.zip>)| Feature area | Spec directory / files |
|-------------|----------------------|
| Deposits/payouts | merchant/merchant-admin-deposits.spec.ts |
| Transactions | merchant/merchant-admin-transactions.spec.ts |
| Disputes | merchant/merchant-admin-disputes.spec.ts, merchant-disputes-*.spec.ts |
| Orders & refunds | merchant/merchant-orders-*.spec.ts |
| Multi-currency | merchant/multi-currency*.spec.ts, merchant/merchant-orders-multi-currency.spec.ts |
| Payment settings | merchant/merchant-payment-settings-*.spec.ts |
| Checkout (shortcode) | shopper/shopper-checkout-*.spec.ts |
| Checkout (blocks) | shopper/ specs tagged @blocks |
| Saved cards | shopper/shopper-saved-card*.spec.ts |
| WooPay | merchant/woopay-setup.spec.ts, shopper/shopper-woopay*.spec.ts |
| Subscriptions | specs/subscriptions/ |
The console shows which test failed and the error message. Look for:
# Screenshots (taken on failure)
ls tests/e2e/test-results/
# Open the HTML report
pnpm exec playwright show-report
# Open a specific trace
pnpm exec playwright show-trace tests/e2e/test-results/<test-folder>/trace.zip
The E2E WordPress site stays running after tests:
admin, Password: password# WordPress container logs
docker logs wcp_e2e_wordpress --tail 50
# Server container logs (local server mode)
docker logs transact_platform_server_wordpress_e2e --tail 50
# MySQL logs
docker logs wcp_e2e_mysql --tail 50
pnpm run test:e2e-ui tests/e2e/specs/wcpay/merchant/failing-test.spec.ts
Open http://localhost:8077 in your browser. UI mode lets you:
| Test type | Directory |
|-----------|----------|
| Merchant tests | tests/e2e/specs/wcpay/merchant/ |
| Shopper tests | tests/e2e/specs/wcpay/shopper/ |
| Subscription merchant | tests/e2e/specs/subscriptions/merchant/ |
| Subscription shopper | tests/e2e/specs/subscriptions/shopper/ |
import { test, expect } from '@playwright/test';
import { getMerchant, getShopper } from '../../utils/helpers';
test.describe( 'Feature description', () => {
test( 'should do something specific', async ( { browser } ) => {
const { merchantPage } = await getMerchant( browser );
// ... test steps
} );
} );
getMerchant(browser) / getShopper(browser) for role-based browsingpage.getByRole(), page.getByLabel(), page.getByText()page.getByTestId() as fallback, CSS selectors as last resortDefined in tests/e2e/config/default.ts:
4242424242424242 — basic successful card4000002760003184 — 3DS authentication required4000000000000002 — declined4000000000000259 — triggers fraudulent dispute| Service | URL | Container |
|---------|-----|-----------|
| E2E WordPress | http://localhost:8084 | wcp_e2e_wordpress |
| E2E MySQL | localhost:5698 | wcp_e2e_mysql |
| E2E phpMyAdmin | http://localhost:8085 | wcp_e2e_phpmyadmin |
| Transact Server | http://localhost:8088 | transact_platform_server_wordpress_e2e |
| Playwright UI | http://localhost:8077 | (via docker-compose) |
pnpm run test:e2e-setup # First-time: build + start + configure everything
pnpm run test:e2e-up # Start existing containers (no reconfigure)
pnpm run test:e2e-down # Stop containers
pnpm run test:e2e-cleanup # Remove deps and docker volumes
pnpm run test:e2e-reset # Stop + cleanup (full teardown)
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when implementing any feature or bugfix, before writing implementation code
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Expert guidance for systematic backtesting of trading strategies. Use when developing, testing, stress-testing, or validating quantitative trading strategies. Covers "beating ideas to death" methodology, parameter robustness testing, slippage modeling, bias prevention, and interpreting backtest results. Applicable when user asks about backtesting, strategy validation, robustness testing, avoiding overfitting, or systematic trading development.
Cloud laboratory platform for automated protein testing and validation. Use when designing proteins and needing experimental validation including binding assays, expression testing, thermostability measurements, enzyme activity assays, or protein sequence optimization. Also use for submitting experiments via API, tracking experiment status, downloading results, optimizing protein sequences for better expression using computational tools (NetSolP, SoluProt, SolubleMPNN, ESM), or managing protein design workflows with wet-lab validation.
This skill should be used for time series machine learning tasks including classification, regression, clustering, forecasting, anomaly detection, segmentation, and similarity search. Use when working with temporal data, sequential patterns, or time-indexed observations requiring specialized algorithms beyond standard ML approaches. Particularly suited for univariate and multivariate time series analysis with scikit-learn compatible APIs.
Take automattic/e2e-testing from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.
The instructions reference npm, docker.
Without those the skill loads but fails at the first command.