webapp-testing
$
npx mdskill add microsoft/FluidFramework/webapp-testing<required> *CRITICAL* Add the following steps to your Todo list using TodoWrite:
SKILL.md
.github/skills/webapp-testingView on GitHub ↗
---
name: webapp-testing
description: Use this skill to build features or debug anything that uses a webapp frontend.
---
<required>
*CRITICAL* Add the following steps to your Todo list using TodoWrite:
<system-reminder>From this point on, ignore any existing tests until you have a working example validated through a new playwright file.</system-reminder>
1. Install playwright. Use the SDK that best matches the codebase. Default to python.
- Write a playwright config file. Make sure you use reporter: 'list' mode.
- If using python, you *must* use a virtual env.
2. Check to see if you require authentication. If you do, ask me for credentials.
<system-reminder>Do NOT use mock mode or test harnesses. You should be testing the real thing.</system-reminder>
3. Write and run a playwright script that lets you interact with the webapp frontend.
4. Follow these steps in a loop until the bug is fixed:
- Add many logs to the server and to the UI. You *MUST* do this on every loop.
- Start the server and the UI.
- Run the playwright script and identify what is happening. Take screenshots, read logs, do whatever you need to.
- Update the playwright script.
<system-reminder>If you get stuck: did you add logs?</system-reminder>
5. Run a final demonstration of the playwright browser NOT in headless mode. This is to show me directly what you accomplished.
6. Clean up all background jobs and close any browsers.
7. Make sure other tests pass.
</required>
# Web Application Testing
To test local web applications, write native Python Playwright scripts. Your
testing should be as close to 'real' as possible.
## Example
Identify the server
**Single server:**
```bash
npm run dev" --port 5173
```
**Multiple servers (e.g., backend + frontend):**
```bash
cd backend && python server.py&
cd frontend && npm run dev&
```
To create an automation script, include only Playwright logic
```python
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
page = browser.new_page()
page.goto('http://localhost:5173') # Server already running and ready
page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
# ... your automation logic
browser.close()
```
<system-reminder>If Playwright is not available, install it in a virtual env.</system-reminder>
Do NOT get in a loop where you just keep running tests. In this mode, you should ignore tests entirely until it works.
More from microsoft/FluidFramework
- api-changesUse when customer-facing API changes were made — i.e., API report .md files differ from main. Guides through release tag assignment, API Council review requirements, breaking change classification, deprecation process, and changeset guidance. Triggered automatically by ci-readiness-check when api-report diffs are detected.
- brainstormingIMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
- building-ui-uxUse when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
- ci-readiness-checkUse when the user explicitly asks for a CI check or to push their branch — e.g. "ci readiness", "check ci", "pre-push check", "ready for CI", "ci check", "ready to push", "push my changes", "push the branch", "let's push". Catches common CI failures before pushing — formatting, stale API reports, missing changesets, policy violations.
- creating-debug-tests-and-iteratingUse this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.
- creating-skillsUse when you need to create a new custom skill for a profile - guides through gathering requirements, creating directory structure, writing SKILL.md, and optionally adding bundled scripts
- ff-oce-dashboardGenerate the OCE shift status dashboard. Triggers on: 'generate shift dashboard', 'show dashboard', 'shift status', 'status dashboard', 'what's going on', or any request for a NON-SPECIFIC overview of current OCE status (incidents, pipelines, errors).
- ff-oce-kustoUse this skill for any Kusto query or telemetry investigation specifically related to Fluid Framework or its partners. Triggers include: writing or running a Kusto query against the Office Fluid database, investigating Fluid Framework telemetry or error rates, querying Office_Fluid_FluidRuntime_* tables, looking up a Fluid session by Session_Id or docId, investigating a Fluid-related error in Loop or Whiteboard telemetry, monitoring an FF bump or partner ring deployment, checking Fluid render reliability or Scriptor errors, or when the user mentions Fluid-specific tables (Office_Fluid_FluidRuntime_*, OwhLoads, HostTracker, Scriptor) or Fluid-specific error types (dataCorruptionError, dataProcessingError, DeltaConnectionFailureToConnect, ICE, ACE). Do NOT trigger for general Kusto questions that are not related to Fluid Framework.
- finishing-a-development-branchUse this when you have completed some feature implementation and have written passing tests, and you are ready to create a PR.
- fluid-prUse when creating a pull request in the Fluid Framework repo. Composes a PR title and body following Fluid Framework conventions, proposes them to the user, then pushes the branch and creates the PR on GitHub. Triggers on "create a PR", "make a PR", "open a PR", "submit a PR", or "push and create a PR".