E-mailverificatie testen is het onderdeel van een registratieflow dat de meeste teams één keer oefenen, op het gelukkige pad, en daarna als afgerond verklaren. De interessante storingen liggen elders: een link die twee keer wordt geopend, een link die in een andere browser wordt geopend, een code die aankomt nadat de gebruiker al is geverifieerd, een bericht dat helemaal nooit aankomt. Dit artikel loopt de toestanden door die een verificatieflow echt heeft en de gevallen die in elk daarvan de moeite waard zijn.
De toestanden die een verificatieflow doorloopt
Schrijf voordat je een test schrijft de toestanden op. Een flow die wordt beschreven als geverifieerd of niet geverifieerd, verbergt minstens vier verschillende situaties, en elk daarvan heeft zijn eigen juiste gedrag.
| Toestand | Wat het systeem gelooft | Wat de gebruiker kan doen |
|---|---|---|
| Niet geverifieerd, geen mail verzonden | Het account bestaat maar is niet bewezen | Om een ander bericht vragen |
| Niet geverifieerd, bericht onderweg | Er bestaat een token met een levensduur | Wachten, of opnieuw vragen |
| Geverifieerd | Het adres is bewezen door een geldig token | Het account normaal gebruiken |
| Wijziging in behandeling | Een nieuw adres is voorgesteld, het oude is nog geldig | Bevestigen of annuleren |
De meeste defecten leven in de overgangen, niet in de toestanden. Vraag wat er gebeurt wanneer een gebruiker een tweede bericht aanvraagt terwijl het eerste nog onderweg is, of het nieuwe adres bevestigt terwijl hij nog is ingelogd op het oude.
Wat breekt er wanneer een bevestigingslink twee keer wordt geopend?
Er zou niets moeten breken, en dat is precies waarom het de moeite waard is om te testen. Een bevestigingslink wordt bezorgd via een kanaal dat de gebruiker niet volledig beheert: mailclients bekijken links voor, beveiligingsscanners volgen ze, en gebruikers klikken er uit ongeduld een tweede keer op.
Het gedrag dat je wilt, is dat het eerste geldige gebruik de flow verbruikt en elk later gebruik een duidelijke, onschadelijke uitkomst oplevert — een pagina met “al geverifieerd”, of een inlogprompt — in plaats van een fout die de gebruiker niet kan uitleggen. Wat je niet wilt, is een tweede verificatiegebeurtenis die een wachtwoord reset, een sessie opnieuw uitgeeft of faalt met een bericht dat suggereert dat het account kapot is.
Er is een verwant geval dat teams verrast: twee accounts, één adres. Als je product hetzelfde adres op twee accounts toestaat, mag één bevestigingsbericht niet in staat zijn om beide te verifiëren. Test dat bewust.
De paden voor e-mail wijzigen en resetten testen
Het wijzigen van een adres en het resetten van een wachtwoord hergebruiken dezelfde machinerie met een andere consequentie, en daar begint een gedeelde implementatie te lekken.
Wanneer een gebruiker een adres wijzigt, bestaan beide adressen een tijdje. Het oude moet nog steeds het account kunnen herstellen, en het nieuwe mag pas ingaan nadat het is bewezen. Wanneer een gebruiker een wachtwoord reset, mag de bevestiging niet ook als verificatie dienen, en omgekeerd. Deze paden testen betekent controleren dat een token dat voor het ene doel is aangemaakt door het andere wordt geweigerd, wat een kleine assertie is die een grote klasse van bugs voorkomt.
Een nuttige fixture voor dit werk is een postvak dat geen enkel ander geval gebruikt, zodat het bericht dat je opent zeker het bericht is dat de flow net heeft verzonden. De tijdelijke mailtool maakt precies dat soort adres aan, en het artikel over OTP testen in end-to-end suites behandelt het extraheren van de code zodra die binnenkomt.
Wat moet er gebeuren wanneer de mail nooit aankomt?
Dit is het pad dat teams overslaan, en het is het pad dat gebruikers het vaakst tegenkomen, omdat mail faalt om redenen die niemand beheerst: een typefout in het adres, een provider die het bericht stil weggooit, een afzender die tijdelijk wordt afgeknepen.
De flow moet niet-aankomst als een normale uitkomst behandelen. De gebruiker moet om een ander bericht kunnen vragen zonder onredelijk lang te wachten, de interface moet duidelijk zeggen dat het bericht even kan duren, en het account mag niet achterblijven in een toestand waarin de gebruiker niet opnieuw kan vragen omdat een verzoek “al in behandeling” is. Niets hier is een specifiek aantal seconden of pogingen; het punt is dat het ontwerp überhaupt een antwoord heeft.
Een code lezen uit een wegwerppostvak
Wanneer een flow een korte code stuurt in plaats van een link, heeft de test de code uit het bericht nodig. Die lezen uit een postvak dat voor de run is aangemaakt, houdt de assertie nauw: het bericht dat je vindt kan alleen bij het geval horen dat je uitvoert, wat de meest voorkomende oorzaak wegneemt van een test die om de verkeerde reden slaagt.
Het houdt ook echte postvakken volledig buiten de test. Het adres van een collega zou nooit de ontvanger van je regressiesuite mogen zijn, zowel omdat diegene het verkeer ontvangt als omdat je asserties dan zouden afhangen van een postvak dat je niet beheert.
Voor ontwikkelaars: tokens, idempotentie en het ongelukkige pad
Modelleer het token, niet alleen het formulier. Drie eigenschappen verdienen expliciete dekking.
Eenmalig gebruik is de eerste. Een token moet één keer kunnen worden verbruikt, en de tweede poging moet een goedaardige uitkomst zijn in plaats van een serverfout. Waar de overgang iets ingrijpends verandert, maak de bewerking dan idempotent zodat een herhaling dezelfde eindtoestand oplevert in plaats van een tweede effect.
Verval is de tweede. Verlopen tokens moeten in je logs en vanuit het oogpunt van de gebruiker te onderscheiden zijn van ongeldige, omdat de oplossingen verschillen: een verlopen token betekent opnieuw beginnen, een ongeldig token kan betekenen dat de verkeerde link is gekopieerd. Wat een verlopen token niet mag doen, is het account in een half gewijzigde toestand achterlaten.
Gelijktijdigheid is de derde. Twee kliks die samen aankomen, of een link die in twee tabbladen wordt geopend, mogen dezelfde flow niet twee keer kunnen verifiëren. Dat is een eigenschap van de datalaag, niet van de knop, dus test het door beide verzoeken te versturen in plaats van langzaam twee keer te klikken.
Houd ten slotte de grens duidelijk in je fixtures en in je notities: deze adressen bestaan om even testmail te ontvangen, het zijn geen echte identiteiten, en geen enkele fixture mag iets anders suggereren.
Volgende stappen
Neem de verificatieflow die je het laatst hebt uitgebracht en loop de bovenstaande toestandstabel door, waarbij je de overgangen markeert die je daadwerkelijk hebt getest. Voer daarna de overgangen uit die je nog niet hebt getest, met een adres dat voor elk geval vers is aangemaakt via de tijdelijke mailpagina. Als je een bredere lancering voorbereidt, behandelt de checklist voor transactionele e-mail de omringende mail die een geverifieerd account zal beginnen te ontvangen.