A tag selects tests. It does not prove coverage.

A pipeline runs the tests tagged @critical and reports green. Someone calls that full regression coverage. The tag selected a subset; it did not demonstrate that the subset represented every important journey. A selection mechanism and a risk judgment are different things.

This guide follows Playwright's annotations documentation with two invented local tests. One belongs to a small review set, the other to a wider inspection set. There is no production pipeline claim or measured coverage percentage. We make the membership visible before interpreting the result.

Define what the tag means

Playwright supports tags in a test details object or in the title. Tags start with @ and can be used to filter tests. A useful team convention gives a tag a short meaning: for example, an agreed small set required for a particular change gate.

Do not let @critical mean whatever the latest author considers important. Name the owner of the selection rule, the journeys it includes and the cases it deliberately excludes. A tag string is easy to add; the reason for membership is the work.

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

test('demo title contract', { tag: '@demo-review' }, async () => {
  expect('Demo review').toBe('Demo review');
});

test('demo archive contract', { tag: '@demo-wide' }, async () => {
  expect(['draft', 'archive']).toContain('archive');
});

These tiny examples demonstrate metadata and selection only. They do not exercise an application or establish useful product coverage. List the selected tests before running the subset:

npx playwright test demos/selection.spec.mjs --grep @demo-review --list

Our local check confirms that only the title contract is selected. Running that subset passes one invented assertion. The excluded archive contract is not counted as executed evidence, even though it also exists in the source tree.

Keep selection separate from skip and expected failure

The annotations guide distinguishes skip, fixme and fail. A skipped or fixme test does not run. A test marked fail does run and is expected to fail; an unexpected pass is reported. These are different states from a test absent because a filter did not select it.

Report selected, executed, skipped and expected-failure cases clearly enough that readers know what green describes. Do not combine them into a single reassuring count. A quiet test may be excluded, disabled or genuinely passing; the report must show which.

Focused tests are another boundary. The guide documents that when focused tests exist, only those run. A local focus used for debugging should not silently narrow the shared suite. Review selection changes alongside test changes rather than only inspecting assertion text.

Check the selected set as it changes

Add a new journey and verify its intended membership. Renaming a title, changing a tag or updating a regular-expression filter can alter selection without changing the test body. Use the runner's list output to inspect the actual set under the exact command used by the pipeline.

Our example uses a simple tag, but more complex filters need their own checks. Do not infer selection from a filename or a dashboard label. Keep the command, relevant configuration and selected test names with the result.

Use the result within its scope

A small gate can give fast feedback while a wider suite runs separately. That is a plan, not proof that the small set catches everything. Let product risk decide the split, and revisit the split when features or failure patterns change.

AnyTest describes agents discovering journeys and producing reviewable tests. Review where a generated test belongs as well as what it asserts. This guide claims no AnyTest tagging interface. An honest result names the tests that ran and does not borrow confidence from the ones that did not.