Playwright Trace Viewer: felsök AI-byggda gränssnitt

1. Bygg ett minimalt formulärfel

Du behöver ett projekt med Node.js, Playwright Test och dess Chromium installerade. Kör exemplen i en separat övningsmapp. Här används ett påhittat kontaktformulär och syntetiska uppgifter. Guidens kod är ett föreslaget prov; den beskriver förväntade resultat och redovisar inga genomförda körningar.

Skapa filen form.html nedan. Felet är avsiktligt: efter ett svar skriver formuläret ”Skickat”, oavsett svarets innehåll. Kravet är att ett avvisat formulär ska visa feltexten och låta dig försöka igen. Det ger ett konkret användarbeteende att undersöka. Bakgrunden till att först avgränsa felet finns i guiden om felsökning med AI.

<!doctype html>
<html lang="sv"><meta charset="utf-8"><title>Formulärprov</title>
<form id="contact">
  <label for="email">E-post</label>
  <input id="email" name="email" type="email" required>
  <button>Skicka</button>
</form>
<p role="status"></p>
<script>
const form = document.querySelector('#contact');
const status = document.querySelector('[role="status"]');
form.addEventListener('submit', async (event) => {
  event.preventDefault();
  const options = {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email: form.elements.email.value })
  };
  const response = await fetch('/api/contact', options);
  status.textContent = 'Skickat';
});
</script></html>

Spara servern som server.cjs i samma mapp och starta den med node server.cjs. Låt terminalen vara öppen. Den serverar övningsformuläret och ett bestämt felsvar; använd den bara för det här lokala provet.

const http = require('node:http');
const fs = require('node:fs');
http.createServer((req, res) => {
  if (req.method === 'POST' && req.url === '/api/contact') {
    res.writeHead(422, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ message: 'Adressen kunde inte användas' }));
    return;
  }
  res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  res.end(fs.readFileSync('form.html'));
}).listen(4173, '127.0.0.1');

Öppna http://127.0.0.1:4173, fyll i test@example.com och tryck på Skicka. Det manuella facit före rättningen är texten ”Skickat”, trots att servern avvisar anropet. Om sidan inte laddas behöver du först lösa serverstarten eller portkonflikten. Det är ett annat problem än formulärets felhantering.

2. Spela in felet deterministiskt

Skapa tests/form.spec.ts med testet nedan. Testets uppgift är att kontrollera det synliga felmeddelandet efter serverns avslag. Det använder samma e-postadress och samma serverrespons vid varje körning. Behåll testet i versionshanteringen så att en senare ändring inte kan ta bort felhanteringen utan ett tydligt utslag.

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

test('visar serverns felmeddelande', async ({ page }) => {
  await page.goto('http://127.0.0.1:4173');
  await page.getByLabel('E-post').fill('test@example.com');
  await page.getByRole('button', { name: 'Skicka' }).click();
  await expect(page.getByRole('status'))
    .toHaveText('Adressen kunde inte användas');
});

Kör från övningsmappen. Med --trace on spelar Playwright in körningen; kommandot dokumenteras i Playwrights Trace Viewer-guide. Vi sätter retries till noll så att utfallet gäller just den första körningen.

npx playwright test tests/form.spec.ts --trace on --retries 0 --workers 1

Förväntat resultat före rättningen: kontrollen av feltexten faller. Om testet i stället faller på navigeringen, etiketten eller knappen har du ännu inte reproducerat det avsedda felet. Läs första felmeddelandet och rätta övningens uppställning innan du ber assistenten ändra applikationslogiken.

För återkommande körningar kan du välja trace: 'retain-on-failure' i konfigurationens use-block. Det behåller inspelningar från misslyckade körningar. Läget on-first-retry spelar däremot in första omkörningen och kräver att en sådan faktiskt sker. Med retries noll får du ingen inspelning från det läget. Skillnaden framgår av dokumentationen om inspelningsalternativ. Välj läge efter vilket försök du behöver undersöka.

3. Öppna din trace lokalt

Leta efter trace.zip i testets resultatmapp. Playwright anger att inspelningar normalt hamnar under test-results; en egen outputDir kan flytta dem. Ersätt exempelvägen nedan med den fil som skapades vid din körning. Öppna inte av misstag en äldre inspelning från ett annat test.

npx playwright show-trace "test-results/ditt-test/trace.zip"

Välj fyllningen och sedan klicket i Actions. Trace Viewer kan visa DOM-snapshots före och efter en åtgärd. Kontrollera att rätt fält fick testadressen och att Skicka var målet för klicket. En snapshot är ett tillstånd vid en viss punkt: den direkt efter klicket behöver inte visa det senare, asynkrona svaret. Undersök också den misslyckade kontrollen längre fram.

4. Skilj locatorfel från nätverksfel

Följ tabellen uppifrån. En locator är testets sätt att hitta ett element. Ett fel där innebär att testet inte nådde det avsedda formulärsteget, medan ett avvisat anrop visar att undersökningen kommit längre.

Network visar bland annat metod, status och svarskropp; tidslinjens urval kan filtrera vilka anrop som visas. Bredda urvalet om du saknar ett anrop. Dessa funktioner beskrivs i Trace Viewer-guiden ovan. I övningen ska du hitta status 422 och meddelandet ”Adressen kunde inte användas”. Skriv ned båda, tillsammans med den text som faktiskt syns i statusrutan.

5. Ge AI ett minimerat felunderlag

Skicka den lilla händelsehanteraren, testet och observationerna till kodassistenten. Lägg till versionsnumret från npx playwright --version och vilket kommando du körde. Hela inspelningen behövs inte för att beskriva just den här skillnaden mellan svar och visning. Använd följande uppdrag när dina observationer stämmer med övningen:

Formuläret skickar POST /api/contact. Svaret är 422 med
{"message":"Adressen kunde inte användas"}.
DOM visar Skickat efter svaret. Kravet är att visa felmeddelandet.
Det bifogade testet faller på statusrutans text.
Rätta bara formulärets svarshantering. Behåll testets förväntan.
Visa diffen och förklara hur fel- och lyckat svar behandlas.
Redovisa vad du har kört och vad som återstår att kontrollera.

Bedöm förslaget mot samma krav som prompten. En ändring som gör testet nöjt genom att förvänta ”Skickat” uppfyller inte uppdraget. Kontrollera också att assistenten inte hårdkodar feltexten för alla svar. En liten diff gör det lättare att se om den faktiskt använder svarets status.

6. Verifiera rättningen och hantera spårfilen

En möjlig rättning är att ersätta just de två raderna som hämtar svaret och uppdaterar status. Före och efter nedan använder samma namn och samma plats i händelsehanteraren:

// Före
const response = await fetch('/api/contact', options);
status.textContent = 'Skickat';

// Efter
const response = await fetch('/api/contact', options);
const data = await response.json();
status.textContent = response.ok ? 'Skickat' : data.message;

Kör samma testkommando igen. Facit efter rättningen är ett passerande test med oförändrad förväntan. Byt sedan till ett lyckat svar i en separat testvariant och kontrollera att ”Skickat” fortfarande visas. För en verklig app behöver du även bestämma beteendet vid nätverksavbrott och oväntat svarsformat; den lilla rättningen ovan förutsätter övningens JSON-svar.

Spara vilket kodläge som föll, vilket som passerade och kommandot som användes. Du får då ett regressionstest med en dokumenterad orsak till att det finns. I guiden om testning av AI-genererad kod kan du gå vidare från detta enskilda fall till fler gränsfall.

En trace kan innehålla sidinnehåll och nätverkets request- och response-data. Använd därför syntetiska uppgifter som i övningen och granska innehållet innan du delar filen. Lägg inte råa inspelningar i en publik felrapport. Bestäm var de får sparas och rensa dem när felsökningsunderlaget inte längre behövs. Ett test och en kort avidentifierad observation räcker ofta som långsiktig dokumentation.