Wacht op het resultaat, niet op de klok

Een instellingenformulier wordt langzaam opgeslagen. Iemand voegt een pauze van twee seconden toe voordat hij het succesbericht controleert. Het wordt doorgegeven aan hun laptop. De volgende CI-run duurt iets langer en mislukt. Een andere ontwikkelaar verandert de pauze in vijf seconden. De test verloopt nu langzamer, maar de reden waarom deze door zou moeten gaan ontbreekt nog.

De nuttige vraag is niet hoeveel seconden je moet slapen. Het bewijs zegt dat de volgende stap klaar is. Deze handleiding bouwt een kleine controle op van opgeslagen instellingen rond die vraag, met behulp van Playwright's beweringsdocumentatie en de gids met best practices. De schermafbeelding is een illustratieve lokale demo, geen klantapplicatie of productbenchmark.

Een pauze raadt. Een voorwaarde controleert.

Als u in de demo op Opslaan klikt, verandert een statuselement na een vertraging van Opslaan in Opgeslagen. Bij een onmiddellijke zichtbaarheidsquery wordt een momentopname van het heden gemaakt. Het wacht niet op een toekomstige staat. De web-first-beweringen van Playwright controleren herhaaldelijk de locator totdat de verwachte voorwaarde geldt of de time-out verloopt.

Vergelijk de twee benaderingen in een test waarbij een pagina al naar uw eigen staging-instellingenformulier is genavigeerd:

// A fixed delay does not express the requirement.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await page.waitForTimeout(2000);
expect(await page.getByRole('status').innerText()).toBe('Saved');

// The expected state controls when the check finishes.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await expect(page.getByRole('status')).toHaveText('Saved');

Dit zijn alternatieve fragmenten, geen instructies om twee keer in één test te klikken. De tweede bewering kan eindigen zodra Opgeslagen verschijnt. Als het nooit verschijnt, mislukt de bewering in plaats van voor onbepaalde tijd te wachten. De standaardtime-out voor de bewering is vijf seconden volgens de huidige beweringdocumentatie; kies alleen een lokale time-out als het verwachte gedrag van uw product dit rechtvaardigt.

Automatisch wachten is niet hetzelfde als wachten op de uitkomst

Playwright controleert de uitvoerbaarheid vóór acties zoals een klik. Een knop moet mogelijk zichtbaar, stabiel en ingeschakeld zijn en gebeurtenissen kunnen ontvangen. Dat geeft antwoord op de vraag of de klik kan plaatsvinden. Het bewijst niet dat het opslagverzoek is voltooid of dat de server de nieuwe instelling heeft behouden.

Een successtatus kan een redelijke gereedheidsvoorwaarde zijn voor de volgende UI-stap, maar is geen onafhankelijk bewijs van volharding. Houd deze taken gescheiden: wacht op Opgeslagen, laad de instellingenpagina opnieuw en controleer vervolgens de geselecteerde waarde. Ons eerdere artikel over onafhankelijke uitkomsten bespreekt die bewijsgrens; deze gids richt zich op het synchronisatiemechanisme waarmee u op betrouwbare wijze bij de controle komt.

await expect(page.getByRole('status')).toHaveText('Saved');
await page.reload();
await expect(page.getByLabel('Display name')).toHaveValue('Demo user');

In het voorbeeld wordt uitgegaan van een toegankelijk veld met de naam Weergavenaam en een herlaadveilige stagingrecord. Definieer die contracten in de demo of uw app. Wijzig het profiel van een live gebruiker niet om een ​​timingexperiment gemakkelijker te maken.

Als het wachten mislukt, blaas hem dan niet eerst op

Een verlopen beweringtime-out is bewijsmateriaal dat moet worden geïnspecteerd. De status wordt mogelijk nooit bijgewerkt. De test kan zich richten op een oud onderdeel. Het opslaan kan mislukken. Of het product kan legitiem langer duren dan de huidige verwachting. Inspecteer de actie en de resulterende gebruikersinterface voordat u een time-out wijzigt.

In de [actionability guide] van Playwright (https://playwright.dev/docs/actionability) wordt uitgelegd welke acties wachten en welke beweringen opnieuw proberen. Generieke gelijkheidscontroles verwerven dat gedrag niet simpelweg omdat er een verwachte waarde in zit. Geef de voorkeur aan een locatorbewering voor een veranderende UI-conditie; gebruik een begrensde polling-bewering wanneer de voorwaarde buiten die vorm ligt.

Zorg ervoor dat elke fout niet verandert in een grotere gedeelde time-out. Een langer plafond verbergt de symptomen en kan ervoor zorgen dat een afgebroken run veel langer duurt. Schrijf het beoogde gereedheidssignaal op en wie de eigenaar is. Als er geen signaal is, kan een duidelijker laadstatus of testcontract een betere oplossing zijn dan nog een keer slapen.

Een beoordelingskaart voor gegenereerde tests

Registreer voor elke timinggevoelige stap de actie, de gereedheidstoestand, de reden van de time-out en de uiteindelijke controle van het resultaat. In onze demo: Opslaan is de status gelijk aan Opgeslagen, het overeengekomen opslagantwoordvenster, waarna het veld na herladen blijft bestaan. Deze kleine kaart is gemakkelijker te beoordelen dan een stapel pauzes.

AnyTest beschrijft dat agenten een web-app verkennen en end-to-end-tests bouwen voor menselijke beoordeling. Als een gegenereerde stroom te snel of onbetrouwbaar lijkt, moet de recensent zich afvragen wat elke transitie gereed maakt. Dit is een beoordelingsprincipe en geen claim dat AnyTest Playwright-instellingen of gegenereerde code in een bepaald formaat openbaar maakt.

Eén enkele QA-ingenieur heeft er voordeel bij als de synchronisatieregels expliciet genoeg zijn voor ontwikkelaars om te onderhouden. Een team zonder speciale QA kan dezelfde kaart gebruiken tijdens codebeoordeling. Het doel is een test die op de juiste reden wacht, faalt met een bruikbare grens en nooit een pauze voor bewijs aanziet.