Testing Agent Skill

by microsoft

Test patterns, fixture structure, and when to use E2E vs unit tests.

2k tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/microsoft/fast --skill testing

The instruction itself

14 sections, as written by the author

Testing

Use this skill when writing or modifying tests in this repository.

Rust crate tests

Unit tests live alongside code in #[cfg(test)] modules. Integration tests go in each crate's tests/ directory.

cargo test -p microsoft-webui-handler   # one crate
cargo test --workspace                   # all crates
cargo xtask test                         # via xtask (part of quality gate)

Every code change ships with tests:

| Change type | Requirement |

|-------------|-------------|

| New public API | At least one unit test per function/method |

| Bug fix | Regression test that fails without the fix |

| Performance change | Benchmark comparison (before/after) |

| Refactor | Existing tests pass unchanged |

Never remove, weaken, or #[ignore] an existing test unless explicitly asked.

Shared test utilities (`webui-test-utils`)

The webui-test-utils crate provides common Rust test helpers, builders, and fixtures. Check it before writing new helpers - avoid duplicating across crates.

[dev-dependencies]
webui-test-utils = { path = "../webui-test-utils" }

webui-framework E2E fixtures

The packages/webui-framework package uses Playwright for E2E tests. Each fixture is a mini WebUI app compiled and rendered by the real pipeline.

See tests/fixtures/README.md for the full reference.

Fixture structure

tests/fixtures/<name>/
  src/
    index.html                 Page template (uses the component)
    <tag-name>/
      <tag-name>.html          Component template (real WebUI syntax)
      <tag-name>.css           Component CSS (optional)
  state.json                   Initial render state (all bound properties)
  element.ts                   Component class (NO template registration)
  <name>.spec.ts               Playwright tests
  webui.config.json            Build options override (optional)

How it works

The test server (fixture-render.ts) auto-discovers fixtures with src/index.html, calls @microsoft/webui build() + render() to produce SSR HTML with template IIFEs, hydration markers, and inventory. The result is served at /<name>/fixture.html.

Creating a new fixture

Create fixtures/<name>/src/index.html — page template:

<!DOCTYPE html>
<html lang="en">
<head><meta charset="utf-8"><title>My Fixture</title></head>
<body>
  <test-widget label="Hello"></test-widget>
</body>
</html>

Create fixtures/<name>/src/test-widget/test-widget.html — component template:

<span class="label">{{label}}</span>
<span class="count">{{count}}</span>
<button class="inc" @click="{increment()}">+</button>

Create fixtures/<name>/state.json — initial state:

{ "label": "Hello", "count": 0 }

Create fixtures/<name>/element.ts — component class only:

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.

import { WebUIElement, attr, observable } from '../../../src/index.js';

export class TestWidget extends WebUIElement {
  @attr label = 'Hello';
  @observable count = 0;

  increment(): void {
    this.count += 1;
  }
}

TestWidget.define('test-widget');

Create fixtures/<name>/<name>.spec.ts — Playwright tests:

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT license.

import { expect, test } from '@playwright/test';

test.describe('widget fixture', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/<name>/fixture.html');
    await page.waitForFunction(() => {
      const el = document.querySelector('test-widget');
      return el && (el as any).$ready === true;
    });
  });

  test('renders SSR content', async ({ page }) => {
    await expect(page.locator('test-widget .label')).toHaveText('Hello');
    await expect(page.locator('test-widget .count')).toHaveText('0');
  });

  test('updates on click', async ({ page }) => {
    await page.locator('test-widget .inc').click();
    await expect(page.locator('test-widget .count')).toHaveText('1');
  });
});

Template syntax quick reference

| Feature | Syntax |

|---------|--------|

| Text binding | {{propertyName}} |

| Event binding | @click="{handler()}" or @click="{handler(e)}" |

| Boolean attribute | ?disabled="{{isDisabled}}" |

| Dynamic attribute | href="{{url}}" |

| Mixed attribute | href="/items/{{id}}" |

| Complex property | :items="{{items}}" |

| Element ref | w-ref="{myElement}" |

| Conditional | <if condition="show">...</if> |

| Negation | <if condition="!hidden">...</if> |

| Comparison | <if condition="count > 0">...</if> |

| Compound | <if condition="active && !busy">...</if> |

| Loop | <for each="item in items">...</for> |

| Nested loop | <for each="group in groups">...<for each="item in group.items">...</for></for> |

| Shadow DOM | <template shadowrootmode="open">...</template> |

| Root event | <template shadowrootmode="open" @click="{handler(e)}"> |

| Slot | <slot></slot> |

Dynamic children pattern

Components only created via document.createElement() (not in any template) need a false <if> in the page template to make their template IIFEs available:

<body>
  <my-host></my-host>
  <if condition="showChild"><my-child></my-child></if>
</body>

With state.json: { "showChild": false }.

Per-fixture build config

Create webui.config.json to override build options:

{ "css": "module" }

Light-DOM fixtures

The pipeline always produces shadow DOM. For light-DOM hydration tests, use manual template registration with registerCompiledTemplate from @microsoft/webui-test-support and a hand-written fixture.html. See fixtures/light-dom/ for the pattern.

Running framework E2E tests

cd packages/webui-framework
pnpm build                    # build the framework
pnpm test                     # unit + E2E tests
npx playwright test           # E2E only
npx playwright test tests/fixtures/<name>/  # one fixture

Test support package (`@microsoft/webui-test-support`)

The packages/webui-test-support package provides:

registerCompiledTemplate(name, meta) — register a raw TemplateMeta object (for manual/light-DOM fixtures)
renderTemplateScript(name, meta) — render a template as an inline <script> tag
renderFixtures({ fixturesRoot }) — build+render all pipeline fixtures
buildFixtureEntries({ ... }) — bundle element.ts files via esbuild
startFixtureServer({ ... }) — start the HTTP fixture server

When to use what

| Scenario | Tool |

|----------|------|

| Rust crate logic (parsing, rendering, state, expressions) | #[test] unit tests |

| Rust crate integration (full pipeline) | tests/ integration tests |

| Rust performance | cargo bench with Criterion |

| Framework hydration, reactive updates, DOM behavior | Playwright E2E fixtures |

| Router navigation, lazy loading, chain diffing | Playwright E2E fixtures |

| Template metadata encoding/decoding | Node unit tests (pnpm test:unit) |

Other skills for the same job

different authors, same section of the catalogue

Webapp Testing

by anthropics

vendor ×12

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.

6k tokens scripts

Finishing A Development Branch

by ZhanlinCui

×7

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

1k tokens

Test Driven Development

by w95

×7

Use when implementing any feature or bugfix, before writing implementation code

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

10k tokens scripts

Verification Before Completion

by ZhanlinCui

×6

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.

19k tokens

How to use it

Copy the folder

Take microsoft/testing from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

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.

Install what it needs

The instructions reference npx. Without those the skill loads but fails at the first command.