Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature]: API request performance metrics and percentile assertions in Playwright Test

Chiusa
  • Qualcosa non va?
#43,709 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
playwright, typescript
Ambito
performance, testing

Direzione di ricerca

Start by reading the @playwright/test request fixture and APIRequestContext implementation, then trace how workers aggregate results and how terminal and HTML reporters report outcomes. The issue proposes request timing, cross-worker percentile aggregation, failure rates, per-operation thresholds, and CI failure behavior, but does not identify files or settle API details; done means measured values and threshold outcomes appear in reports and failing thresholds produce a non-zero exit code.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

🚀 Feature Request

I use @playwright/test for API testing through its request fixture / APIRequestContext. The existing fixtures, authentication, assertions and reporting work well, and I would like to reuse these tests to detect API performance regressions.

Specifically, I would like opt in request performance metrics and aggregate assertions similar to the following k6 capabilities:

  • Latency distributions: minimum, maximum, mean, median, p90, p95 and p99 across repeated requests
  • Request counts and throughput: total requests and achieved requests per second.
  • Failure rates: failed requests as a proportion of total requests, including HTTP failures, network errors and timeouts.
  • Aggregate thresholds: conditions such as p(95)<300, p(99)<750 and rate<0.01, evaluated after collecting samples.
  • Per-operation metrics: stable names for requests so /products/123 and /products/456 can be aggregated as the same operation, with separate thresholds for different endpoints.
  • Reporting and CI integration: measured values, sample counts and threshold outcomes in terminal/HTML reports, with a non-zero exit code when a threshold fails.

For example, k6 allows:

thresholds: {
  http_req_duration: ['p(95)<300', 'p(99)<750'],
  http_req_failed: ['rate<0.01'],
}
Example

The following is illustrative proposed syntax, rather than a requirement for the exact API

export default defineConfig({
	// ...rest of the config,

	// e.g. a proposed configuration
	  performance: {
	    thresholds: {
	      'list-products': {
	        duration: ['p(95)<300', 'p(99)<750'],
	        failureRate: ['rate<0.01'],
	      },
	    },
	  },
});

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

test('list products', async ({ request }) => {
  const response = await request.get('/products', {
    // Proposed option: record this request under a stable operation name.
    performance: { name: 'list-products' },
  });

  expect(response.ok()).toBeTruthy();

  const body = await response.json();
  expect(Array.isArray(body.products)).toBeTruthy();
});

After all repetitions complete, Playwright would aggregate the request samples across workers within the project and evaluate the thresholds.

For example, a run could pass every functional assertion but fail its performance criteria because the measured p95 was 340 ms against a 300 ms threshold. The report would show both outcomes.

Measurement behaviour
  • Measure individual API requests, excluding test setup and assertions.
  • Combine measurements across workers and repetitions before calculating percentiles.
  • Include failed requests and timeouts in the failure rate.
  • Show the number of requests measured alongside the results.
  • Evaluate performance thresholds at the end of the run and fail the run if they are exceeded.

The exact timing boundaries and handling of retries could follow documented defaults.

Motivation

Currently, achieving this requires custom timing, sample collection, aggregation, percentile calculations, threshold evaluation and reporter integration, or maintaining a separate suite in another tool.

workers and repeatEach help execute repeated requests, but do not provide these statistical helpers or aggregate performance assertions.

An initial implementation could focus on API performance regression testing using existing execution controls. More advanced load-generation features, such as virtual users, ramp-up stages and target arrival rates, could be considered separately.

Lingua principale
TypeScript
Stelle
98.5k
Fork
6.7k
Merge medio
17h 5m
PR unite (30g)
326

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/playwright

Tutte le issue di microsoft/playwright

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.