Playwright Test Annotations in TestDino

Annotations let you attach metadata directly to your Playwright tests. Tag each test with priority, feature area, owner, ticket links, Slack targets, and custom metrics. TestDino displays them in the UI next to each test case.

Quick Reference

Topic	Link
Supported annotations	All annotation types TestDino recognizes
Add annotations	How to write annotations in your test code
Custom metrics	Track performance and business metrics per test
View in TestDino	Where annotations show up in the UI
Slack notifications	How `testdino:notify-slack` triggers alerts
Configure Slack mapping	Connect annotation targets to Slack channels or users

Supported Annotations

Annotations use the standard Playwright annotation array. All types use the testdino: prefix.

Annotation Type	Example Value	What it does
`testdino:priority`	`p0`, `p1`, `p2`, `p4`	Tags the test with a priority level
`testdino:feature`	`Navbar`, `Cart`, `Checkout`	Tags the feature area this test covers
`testdino:link`	Jira, Linear, or any URL	Links to a related ticket or document
`testdino:owner`	`qa-team`, `@ashish`	Identifies who owns or maintains this test
`testdino:notify-slack`	`#e2e-alerts`, `@ashish`	Notifies a Slack channel or user when this test fails
`testdino:context`	Free-text description	Adds context that other testers need to know
`testdino:flaky-reason`	`Upload feature depends on file size`	Documents a known reason the test is flaky
`testdino:metric`	JSON with `name`, `value`, `unit`	Tracks a custom numeric metric per test run (details)

Notetestdino:notify-slack triggers Slack notifications when configured. testdino:metric tracks numeric values over time with charts. All other annotation types display in the TestDino UI for reference.

Add Annotations to Tests

Add the annotation array to any Playwright test. Each entry has a type (the annotation name) and a description (the value):

tests/navbar.spec.ts

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

test('Verify navbar', {
  annotation: [
    { type: 'testdino:priority', description: 'p0' },
    { type: 'testdino:feature', description: 'Navbar' },
    { type: 'testdino:link', description: 'https://jira.example.com/NAVBAR-1' },
    { type: 'testdino:owner', description: 'qa-team' },
    { type: 'testdino:notify-slack', description: '@ashish' },
  ],
}, async ({ page }) => {
  await page.goto('/');
  await expect(page.locator('nav')).toBeVisible();
});

You can notify multiple channels and users from a single annotation by separating them with commas:

{ type: 'testdino:notify-slack', description: '#e2e-alerts,#qa-channel,@ashish,@vishwas' }

For better readability, use separate entries:

annotation: [
  { type: 'testdino:notify-slack', description: '#e2e-alerts' },
  { type: 'testdino:notify-slack', description: '#qa-channel' },
  { type: 'testdino:notify-slack', description: '@ashish' },
],

Slack Notification Targets

Format	Example	What happens
`#channel-name`	`#e2e-alerts`	Sends the failure alert to that Slack channel
`@username`	`@ashish`	Sends the failure alert directly to that Slack user
Comma-separated	`#e2e-alerts,@ashish`	Notifies multiple targets from one entry

TipSeparate entries per target are recommended for readability and easier maintenance.

Custom Metrics

The metric annotation type tracks custom numeric values across test runs. Unlike other annotations that store text, metrics store structured data (name, value, unit, optional threshold). TestDino shows each metric in the Annotations panel on the test case and plots a time-series chart per metric name. Use metrics to track anything you measure during a test: page load time, API latency, memory usage, bundle size, Lighthouse scores, or business numbers like conversion rate.

Metric Format

The testdino:metric annotation uses a JSON string as the description:

{
  type: 'testdino:metric',
  description: JSON.stringify({
    name: 'page-load-time',  // Metric name (keep consistent across runs)
    value: 1250,             // Numeric value for this run
    unit: 'ms',              // Display unit
    threshold: 2000,         // Optional: shown next to the value. Use 0 or omit for none.
  }),
}

Field	Required	Description
`name`	Yes	Identifier for the metric. Use the exact same name across runs to build a trend line.
`value`	Yes	Numeric value recorded in this test run
`unit`	Yes	Display unit shown on the chart and labels
`threshold`	No	Target value shown next to the metric in the Annotations panel, formatted as `value unit / threshold` (for example `1234 ms / 2000`). A threshold of `0` or an omitted field shows no target.

Supported Units

Unit	Example use
`ms`	Page load time, API latency
`s`	Full test duration, timeout values
`mb`	Memory usage, bundle size
`gb`	Large asset sizes
`%`	Conversion rate, pass rate
`count`	Error count, API calls per test
`score`	Lighthouse score, accessibility score

Static vs. Runtime Metrics

You can set metric values in two ways depending on your use case. Static values go in the annotation array at test declaration. Use this for values you know ahead of time or compute before the test:

tests/static-metric.spec.ts

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

test('Homepage check', {
  annotation: [
    {
      type: 'testdino:metric',
      description: JSON.stringify({
        name: 'lighthouse-score',
        value: 94,
        unit: 'score',
        threshold: 90,
      }),
    },
  ],
}, async ({ page }) => {
  await page.goto('/');
  await expect(page.locator('h1')).toBeVisible();
});

Runtime values are measured during the test and pushed with test.info().annotations.push(). Use this for performance timings, API latency, or anything captured at execution time:

tests/performance.spec.ts

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

test('Homepage loads within budget', async ({ page }) => {
  const start = Date.now();
  await page.goto('/');
  await expect(page.locator('h1')).toBeVisible();
  const loadTime = Date.now() - start;

  test.info().annotations.push({
    type: 'testdino:metric',
    description: JSON.stringify({
      name: 'page-load-time',
      value: loadTime,
      unit: 'ms',
      threshold: 2000,
    }),
  });
});

TipUse test.info().annotations.push() for any metric that depends on runtime measurement. The annotation array on the test declaration runs before the test body, so it cannot access runtime values.

Example: Track Multiple Metrics at Runtime

A single test can report multiple metrics. Push each one after you capture the value:

tests/checkout.spec.ts

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

test('Checkout flow performance', async ({ page }) => {
  const start = Date.now();
  await page.goto('/checkout');
  await expect(page.locator('[data-testid="order-summary"]')).toBeVisible();
  const flowTime = Date.now() - start;

  // Track the checkout flow duration
  test.info().annotations.push({
    type: 'testdino:metric',
    description: JSON.stringify({
      name: 'checkout-flow-time',
      value: flowTime,
      unit: 'ms',
      threshold: 5000,
    }),
  });

  // Track the number of API calls made during the test
  test.info().annotations.push({
    type: 'testdino:metric',
    description: JSON.stringify({
      name: 'api-calls',
      value: 12,
      unit: 'count',
    }),
  });
});

Common Metric Examples

These show the annotation format for different categories. Replace the value with your actual measurement.

Performance
Quality
Resources

// Page load time
{ type: 'testdino:metric', description: JSON.stringify({ name: 'page-load-time', value: loadTime, unit: 'ms', threshold: 2000 }) }

// API latency
{ type: 'testdino:metric', description: JSON.stringify({ name: 'api-latency', value: latency, unit: 'ms', threshold: 200 }) }

// Memory usage
{ type: 'testdino:metric', description: JSON.stringify({ name: 'memory-usage', value: memoryMb, unit: 'mb' }) }

// Lighthouse score
{ type: 'testdino:metric', description: JSON.stringify({ name: 'lighthouse-score', value: 94, unit: 'score', threshold: 90 }) }

// Accessibility score
{ type: 'testdino:metric', description: JSON.stringify({ name: 'accessibility-score', value: 87, unit: 'score', threshold: 80 }) }

// Error count
{ type: 'testdino:metric', description: JSON.stringify({ name: 'error-count', value: errorCount, unit: 'count' }) }

// Bundle size
{ type: 'testdino:metric', description: JSON.stringify({ name: 'bundle-size', value: 2.4, unit: 'mb', threshold: 3.0 }) }

// API calls per test
{ type: 'testdino:metric', description: JSON.stringify({ name: 'api-calls', value: callCount, unit: 'count' }) }

// Conversion rate
{ type: 'testdino:metric', description: JSON.stringify({ name: 'conversion-rate', value: rate, unit: '%' }) }

How Metrics Display in TestDino

Metric values appear on the test case detail page in two places:

Annotations panel on the test case overview. Each metric shows its name and a value unit / threshold badge, for example page-load-time with 1234 ms / 2000. A threshold of 0 (or omitted) shows the value alone.
Custom Runtime Metrics chart in the Specs Explorer. TestDino plots a time-series chart for each metric name, with the X-axis showing test run timestamps and the Y-axis showing the metric value. Filter by metric name to focus on a specific measurement, and the chart updates as new test runs report values for that metric.

TipKeep metric names consistent across runs. Use the exact same name string every time (for example, always page-load-time, not sometimes pageLoadTime). This ensures all data points appear on the same trend line.

View Annotations in TestDino

Once your tests run, annotations appear in two places in TestDino.

Test Case Detail

Open any test case from a test run. Below the KPI tiles, the Annotations panel lists every annotation on that test: priority, feature, link, owner, Slack targets, context, and flaky reason. Metric values also appear with their name, value, and unit.

Detailed Analysis Table

In the Test Runs > Summary > Detailed Analysis table, each test row has an Annotations badge. Click it to expand and see annotation chips (priority, feature, owner, Slack targets) inline with the test result. This makes it easy to scan annotations across all tests in a run without opening each one.

Annotation-Based Slack Notifications

When a test with a testdino:notify-slack annotation fails, TestDino sends a Slack alert to the mapped channel or user. This works independently from test run alerts, which notify on every run completion regardless of annotations. The notification flow:

Your test has testdino:notify-slack set to @ashish or #e2e-alerts.
The test fails during a run.
TestDino looks up the Annotation-Slack mapping in your Slack App configuration.
If there is a mapping for that target, the alert goes to the configured Slack destination.

WarningAnnotation-based Slack notifications require the Slack App to be connected to your project. The Slack Webhook integration does not support annotation-based alerts.

Configure Annotation-Slack Mapping

The mapping connects the testdino:notify-slack values you write in your test code to actual Slack channels and users in your workspace.

Connect the Slack App

Go to Project Settings > Integrations > Communication > Slack App and connect your Slack workspace. See Slack App setup if you have not connected yet.

Open Annotation Alerts tab

In the Slack Notification Configuration dialog, switch to the Annotation Alerts tab. This is where you define which annotation targets map to which Slack destinations.

Add your mappings

For each annotation target in your test code, add a row and pick the Slack channel or user it should notify:

Annotation Target (from your test code)	Slack Channel / User
`@ashish`	`@ashi-deve`
`@vishwas`	`@Vishwas Tiwari`
`#e2e-alerts`	`#td-stage`

Type in the search box and select from the dropdown. The dropdown lists all channels and users from your connected Slack workspace.

Save the configuration

Click Save. From now on, when a test with a matching testdino:notify-slack annotation fails, the alert is sent to the mapped Slack destination.

Things to Know

Mapping is stored at the integration level, not at the project level.
Disconnecting Slack removes all mappings. If you disconnect the Slack App, all Annotation-Slack mappings are deleted. You need to set them up again after reconnecting.
One test can notify multiple targets. Add separate testdino:notify-slack entries for each channel or user you want to alert.

Example: Full Annotation Setup

This test uses all supported annotation types, including a runtime metric:

tests/order.spec.ts

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

test('New user can place and cancel order', {
  annotation: [
    { type: 'testdino:priority', description: 'p0' },
    { type: 'testdino:feature', description: 'Registration to Order' },
    { type: 'testdino:link', description: 'https://jira.example.com/PROJ-123' },
    { type: 'testdino:owner', description: 'qa-team' },
    { type: 'testdino:notify-slack', description: '#ch-td-extra' },
    { type: 'testdino:notify-slack', description: '@ashish' },
    { type: 'testdino:context', description: 'Uses fixture user: test+fixture-user@example.com' },
    { type: 'testdino:flaky-reason', description: 'Delay in API call response' },
  ],
}, async ({ page }) => {
  const start = Date.now();

  // Test steps: navigate, place order, cancel order
  await page.goto('/orders/new');
  await expect(page.locator('[data-testid="order-confirmed"]')).toBeVisible();

  const flowTime = Date.now() - start;

  test.info().annotations.push({
    type: 'testdino:metric',
    description: JSON.stringify({
      name: 'order-flow-time',
      value: flowTime,
      unit: 'ms',
      threshold: 5000,
    }),
  });
});

When this test runs:

TestDino shows all annotations in the test case Annotations panel.
The order-flow-time metric appears on the test detail page and is plotted on a trend chart across runs.
If the test fails, Slack alerts go to #ch-td-extra and @ashish (if mapped in the Slack App configuration).
The Detailed Analysis table shows annotation chips for quick scanning across all tests in the run.

Slack App

Connect Slack and configure notification channels

Test Cases

View test case details and annotations

Test Runs Summary

Detailed analysis with annotation chips

Node.js CLI

Reporter configuration and CLI options

Getting Started

Installation & Setup

AI & MCP

Guides

Project

Test Management

Organization

Integrations

Data Privacy

Resources

Playwright Test Annotations in TestDino

Quick Reference

Supported Annotations

Add Annotations to Tests

Slack Notification Targets

Custom Metrics

Metric Format

Supported Units

Static vs. Runtime Metrics

Example: Track Multiple Metrics at Runtime

Common Metric Examples

How Metrics Display in TestDino

View Annotations in TestDino

Test Case Detail

Detailed Analysis Table

Annotation-Based Slack Notifications

Configure Annotation-Slack Mapping

Things to Know

Example: Full Annotation Setup

Slack App

Test Cases

Test Runs Summary

Node.js CLI

​Quick Reference

​Supported Annotations

​Add Annotations to Tests

​Slack Notification Targets

​Custom Metrics

​Metric Format

​Supported Units

​Static vs. Runtime Metrics

​Example: Track Multiple Metrics at Runtime

​Common Metric Examples

​How Metrics Display in TestDino

​View Annotations in TestDino

​Test Case Detail

​Detailed Analysis Table

​Annotation-Based Slack Notifications

​Configure Annotation-Slack Mapping

​Things to Know

​Example: Full Annotation Setup

​Related

Slack App

Test Cases

Test Runs Summary

Node.js CLI

Quick Reference

Supported Annotations

Add Annotations to Tests

Slack Notification Targets

Custom Metrics

Metric Format

Supported Units

Static vs. Runtime Metrics

Example: Track Multiple Metrics at Runtime

Common Metric Examples

How Metrics Display in TestDino

View Annotations in TestDino

Test Case Detail

Detailed Analysis Table

Annotation-Based Slack Notifications

Configure Annotation-Slack Mapping

Things to Know

Example: Full Annotation Setup

Related