Back to SDET
Looking for JavaScript fundamentals (variables, promises, classes…)? They live in the JavaScript path.Go to JavaScript →Testkoncept & Övningar
Vilka typer av test doubles finns det?
En test double är vilken ersättare som helst för en riktig komponent. Dummy: skickas men används aldrig. Stub: returnerar fasta fördefinierade värden. Fake: en fungerande men förenklad implementation (t.ex. en databas i minnet). Spy: registrerar hur den anropades utan att ändra beteendet. Mock: en stub plus assertions om hur den anropades (t.ex. att sendEmail anropades en gång).
Varför och när mockar man — och när bör man inte?
Mocka för att isolera enheten som testas från långsamma eller instabila externa beroenden (databas, tredjeparts-API:er, e-post), för att simulera svåråterskapade fel som en
500, och för att hålla tester snabba och deterministiska. Mocka inte när du specifikt vill verifiera verklig integration, när en mock skulle avvika så mycket från verkligheten att den tappar värde, eller när det verkliga beroendet redan är lokalt och snabbt.Hur mockar man nätverksanrop i Playwright?
Använd
page.route för att fånga ett URL-mönster och uppfylla det med ett fördefinierat svar: page.route('**/api/products', r => r.fulfill({ status: 200, body: JSON.stringify(data) })). Du kan returnera en 500 för att testa fel-UI, eller lägga till en fördröjning före route.continue() för att testa laddningstillstånd — allt utan att röra den riktiga backenden.Hur strukturerar man ett CRUD-integrationstest för ett REST-API?
Täck hela livscykeln och auth-/valideringsgränserna: skapa (
POST -> 201), läs tillbaka (GET -> 200), uppdatera delvis (PATCH -> 200, oförändrade fält består), radera (DELETE -> 204) och bekräfta att den är borta (GET -> 404). Lägg till negativa fall: ingen token -> 401, fel roll -> 403, saknat obligatoriskt fält -> 422, dubblett -> 409. Varje test bör sätta upp sin egen data för att förbli oberoende.Vad är TTL och var spelar det roll i testning?
TTL (time to live) är hur länge något förblir giltigt: auth-tokens/sessioner (JWT-utgång), cacheposter (Redis, CDN,
HTTP Cache-Control) och rate-limit-fönster (X-RateLimit-Reset). Som SDET testar du att en utgången token avvisas, att en cachepost blir en miss efter sin TTL, och att begäranden över gränsen stryps och återställs korrekt.Varför undvika fasta sleeps, och vad använder man i stället?
En fast sleep (
waitForTimeout(3000)) är antingen för kort (flaky) eller för lång (långsam), eftersom verklig timing varierar. Använd villkorsbaserade väntningar i stället: waitForSelector för ett element, expect(...).toBeVisible(), waitForResponse för ett API-anrop, eller en generisk polling-hjälpare som kontrollerar ett villkor på nytt fram till en timeout. Detta gör testerna både snabbare och mer pålitliga.Hur fungerar omförsök med exponentiell backoff, och när bör man inte göra omförsök?
Omförsök kör om en misslyckad operation upp till N försök och väntar längre mellan varje försök (delay * 2^försök) så att en kämpande tjänst kan återhämta sig utan att överbelastas. Gör endast omförsök vid övergående fel (nätverksglapp,
5xx, timeouts). Gör inte omförsök vid deterministiska klientfel som 404 eller 422 — ett shouldRetry-predikat låter dig hoppa över dem, eftersom omförsök aldrig kommer att lyckas.