Simuleer de afhankelijkheid. Benoem de grens.

Een leveringsofferte mislukt tijdens een vrijgavecontrole. Is de betaalinterface kapot, is de offerteaanbieder niet beschikbaar of is de testomgeving zijn inloggegevens kwijt? Eén rood resultaat vertegenwoordigt nu meerdere systemen. Een gecontroleerde reactie kan u helpen de gebruikersinterface te onderzoeken, maar verandert de betekenis van het resultaat.

Deze handleiding maakt gebruik van een klein scherm met leveringsoffertes om te laten zien hoe u een afhankelijkheid kunt simuleren en hoe u het bewijs eerlijk kunt labelen. Het is gebaseerd op Playwright's spotgids en netwerkdocumentatie. Het hier getoonde scherm is een lokale illustratieve demo met verzonnen verzendopties, geen klantworkflow of een live service.

Bepaal welke vraag de test beantwoordt

De UI-vraag is of de pagina een geretourneerde prijs weergeeft, een lege lijst verwerkt en een niet-beschikbare offerte uitlegt. De integratievraag is of de echte dienst het verzoek accepteert en de afgesproken antwoordvorm retourneert. U kunt deze afzonderlijk testen en een kleinere real-service controle houden naast een deterministische UI-suite.

Noem het bespotte pad geen volledig end-to-end bewijs voor de dienst. De waarde ervan is kleiner: uw frontend ontvangt bekende gegevens en gedraagt ​​zich correct. Dat is nuttig bewijsmateriaal als het correct wordt genoemd. Een groene gesimuleerde afhankelijkheid kan u niet vertellen of een provider zijn inloggegevens heeft gewijzigd, uw payload heeft afgewezen of is gestopt met het bedienen van uw regio.

Installeer de route voordat het verzoek gebeurt

In deze illustratieve app wordt bij het laden van de offertepagina gevraagd naar /api/delivery-quote. Het voorbeeld onderschept dat exacte pad en retourneert een gecontroleerd JSON-object. Registreer de handler voordat u navigeert, zodat het eerste verzoek niet aan de beoogde instellingen kan ontsnappen.

await page.route('**/api/delivery-quote', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ label: 'Standard', price: '4.00' })
  });
});
await page.goto('/delivery-quote');
await expect(page.getByRole('status')).toHaveText('Standard: 4.00');

Gebruik een geconfigureerde staging baseURL voor deze relatieve navigatie. De antwoordvorm is ons democontract, niet een universele leverings-API. Een echte test moet uw gedocumenteerde schema- en valutaregels gebruiken. Match alleen het eindpunt dat u wilt controleren; het onderscheppen van al het verkeer kan niet-gerelateerde fouten verbergen.

Playwright's Route API maakt onderscheid tussen het vervullen van een verzoek en het ophalen van een echt antwoord en het wijzigen ervan. In het bovenstaande voorbeeld wordt de upstream-offerteservice niet aangeroepen. Een route.fetch()-voorbeeld zou een andere grens hebben, omdat deze nog steeds afhankelijk is van het stroomopwaartse antwoord.

Testmislukkingsstatussen zonder te wachten op een storing van een leverancier

Retourneer een 503-antwoord in een tweede test en controleer vervolgens of de pagina uitlegt dat de offerte niet beschikbaar is en de beoogde volgende actie aanbiedt. Een derde test kan een succesvol leeg resultaat opleveren als dat een betekenisvolle status in uw contract is. Houd elke opzet klein en expliciet.

await page.route('**/api/delivery-quote', route =>
  route.fulfill({ status: 503, body: 'Unavailable' })
);
await page.goto('/delivery-quote');
await expect(page.getByRole('alert')).toHaveText('Quote unavailable');

Deze fragmenten horen thuis in aparte testgevallen. De app moet dat waarschuwingsgedrag implementeren; dit is geen matcher die het maakt. Controleer of een gebruiker een veilige volgende stap heeft, en niet alleen of er een rode tekst verschijnt. Fake nooit een voltooide betaling om te bewijzen dat een echte betaling werkt.

Let op de blinde vlekken

Een servicemedewerker kan verzoeken onderscheppen voordat de pagina- of contextroutering van Playwright ze ziet. In de netwerkdocumentatie wordt aanbevolen om servicemedewerkers te blokkeren wanneer bij native routing verwachte aanvragen ontbreken. Kies die instelling bewust in uw gecontroleerde testconfiguratie; Als u dit wijzigt, kan gedrag worden verwijderd dat u anders zou moeten testen.

Browsercontextrouting kan pagina's en pop-ups binnen de context bestrijken, terwijl een regel op paginaniveau een beperkter bereik heeft. Bepaal welk gedrag u nodig heeft, in plaats van elke regel naar de breedste reikwijdte te verplaatsen. Houd de routebehandelaars en gegevens van de test binnen de levenscyclus ervan.

Opgenomen HTTP-archieven kunnen ook verkeer opnieuw afspelen, maar opnames kunnen gevoelige headers, cookies en responsgegevens bevatten. Controleer en reinig een opname voordat u deze opslaat. Voor dit eenvoudige citaatgeval is een met de hand geschreven antwoord gemakkelijker te inspecteren dan een groot vastgelegd archief.

Geef het bewijsmateriaal een naam die het dashboard overleeft

Gebruik een testtitel, zoals de gebruikersinterface voor leveringsoffertes, een nepreactie van de provider. Vermeld in de beoordelingsnotities het gecontroleerde eindpunt, de contractversie en de afzonderlijke real-service check. Een teamgenoot hoeft de routecode niet te inspecteren om te ontdekken dat de aanbieder afwezig was.

AnyTest beschrijft URL-gestuurde verkenning en tests die mensen kunnen beoordelen. Pas dezelfde bewijsvraag toe op elke voorgestelde stroom: welke afhankelijkheden waren reëel, welke werden gecontroleerd, en wat stelt een pas vast? Deze handleiding claimt geen specifieke spotinterface binnen AnyTest.

Voor een klein QA-team is de beloning een duidelijker diagnosetraject en een doelbewuste dekking van storingsstatussen. Voor een testpakket dat eigendom is van een ontwikkelaar geldt hetzelfde: zorg voor herhaalbare UI-controles, houd de integratiegrens zichtbaar en laat een handige gesimuleerde afhankelijkheid geen grotere belofte worden dan de test kan ondersteunen.