OTP testen is het kleine, koppige onderdeel van een end-to-end suite dat een eenmalige code uit een postvak leest en terug in een formulier typt. Het lijkt triviaal tot het onbetrouwbaar wordt, en het wordt onbetrouwbaar om redenen die niets te maken hebben met een verkeerde code: een traag bericht, een ouder bericht dat nog in het postvak staat, een herverzending die aan een limiet was onderworpen. Dit artikel behandelt hoe je die stap betrouwbaar maakt en wanneer je moet stoppen met automatiseren.
Wat een end-to-end suite nodig heeft van een codebericht
Een codebericht heeft één taak: een kort geheim van je applicatie naar een plek dragen waar de test het kan lezen. Al het andere eraan — opmaak, branding, voettekst, taal — is decoratie vanuit het oogpunt van de suite.
Die asymmetrie is wat de stap zo makkelijk fout doet gaan. Omdat de test maar een handvol tekens nodig heeft, is het verleidelijk om ze losjes te schrapen, uit het eerste bericht dat er dicht genoeg bij lijkt. Het resultaat is een test die meestal slaagt en af en toe het verkeerde bericht leest, wat de duurste soort flake is: zeldzaam genoeg om te worden afgedaan en echt genoeg om een echte bug te verbergen.
Welk bericht is het juiste?
Identiteit, niet alleen recentheid. De veiligste regel is een combinatie: het bericht moet geadresseerd zijn aan het adres dat dit geval heeft aangemaakt, en het moet het nieuwste overeenkomende bericht in dat postvak zijn.
Beide helften verdienen hun plaats. Matchen op de ontvanger verwijdert kruisbesmetting tussen tests, omdat een bericht dat naar het adres van een ander geval is gestuurd de assertie niet kan bevredigen, hoe nieuw het ook is. De voorkeur geven aan het nieuwste onder de overeenkomsten behandelt het geval waarin dezelfde flow twee keer is geactiveerd, één keer door een herhaling of een eerdere poging.
Matchen op onderwerp is een nuttige vernauwende stap wanneer een postvak terecht meer dan één soort mail bevat — bijvoorbeeld een welkomstbericht en een code. Match op een stabiel deel van het onderwerp in plaats van op de hele regel, omdat de decoratieve delen veranderen: hetzelfde onderwerp met een andere begroeting moet nog steeds overeenkomen.
Waarom worden tests die codes lezen onbetrouwbaar?
Vier oorzaken verklaren het meeste, en elk heeft een andere oplossing.
- Een vaste wachttijd. Een constant aantal seconden slapen is een gok, en gokken zijn ofwel te kort wanneer het bericht traag is, ofwel verspillend lang wanneer het snel is. Poll tot het bericht verschijnt, met een bovengrens die de test laat falen in plaats van de run te laten hangen.
- Een oud bericht. Als een geval een adres hergebruikt, of als een eerdere poging een bericht heeft achtergelaten, kan een verse opzoeking zichzelf tevredenstellen met oude inhoud. Geef elk geval een eigen adres, of registreer op zijn minst wat er was voordat de flow begon en negeer alles wat ouder is.
- Een limiet op herverzendingen. Codeflows staan normaal slechts een paar herverzendingen in een kort venster toe, wat een bewuste bescherming is en geen defect. Een test die het opnieuw probeert door om een andere code te vragen, wordt uiteindelijk geweigerd en faalt om de verkeerde reden; probeer het opnieuw door het postvak opnieuw te lezen in plaats van op de knop te drukken.
- Parsen dat te gretig is. Een body kan terecht meerdere getallen bevatten — een referentie, een tijdstempel, een prijs — en een parser die de eerste reeks cijfers pakt, pakt soms de verkeerde. Veranker de extractie aan de bewoording rond de code in plaats van alleen aan de cijfers.
Wanneer moet er een mens in de lus blijven?
Sommige stappen moeten niet worden geautomatiseerd, en doen alsof dat wel kan, levert tests op die niemand vertrouwt.
Een mens is het juiste gereedschap wanneer de flow een apparaat nodig heeft dat een pipeline niet heeft, wanneer de code aankomt via een kanaal dat niet programmatisch kan worden gelezen, of wanneer de assertie in werkelijkheid een oordeel is over of het bericht lekker leest. Er is ook een eenvoudiger geval: sommige providers ontmoedigen geautomatiseerde registratie actief, en een suite die daar omheen werkt, test niet het product, maar de omweg.
Het nuttige patroon is een expliciete handmatige poort die luidruchtig faalt in plaats van stilzwijgend te slagen. Een stap die zegt “een persoon moet dit controleren voordat de run verdergaat” is eerlijk; een stap die het probeert en af en toe slaagt, is dat niet.
Een wegwerppostvak voor elke run
De schoonste fixture voor dit werk is een postvak dat is aangemaakt voor het geval dat het nodig heeft en daarna wordt weggegooid. Omdat er nooit iets anders naartoe is gestuurd, is het nieuwste bericht vrijwel zeker het juiste, en verdwijnt het versheidsprobleem grotendeels.
De tijdelijke mailpagina maakt een adres op aanvraag aan: kies een maildomein, geef het optioneel een voorvoegsel, en er verschijnt een postvak dat vermeldt wat er aankomt. Codes worden apart naar boven gehaald zodat ze kunnen worden gekopieerd zonder de hele body te lezen, wat handig is wanneer een mens leest en nuttig om na te bootsen wanneer software leest.
Deze adressen zijn steigers voor een testrun. Ze staan voor niemand, ze worden met de run weggegooid, en ze mogen nooit als echte identiteit worden vastgelegd of als contactpunt van wie dan ook worden gebruikt.
Voor ontwikkelaars: parsen, versheid en bovengrenzen bij herhalingen
Vijf beslissingen maken het verschil tussen een suite die codes leest en een suite die daarin wordt vertrouwd.
Geef elk geval een eigen adres, en laat het adres de identiteit van het geval dragen, zodat een bericht kan worden toegeschreven door er naar te kijken in plaats van door timing.
Poll met een bovengrens, en maak de bovengrens deel van het faalbericht. Wanneer die wordt geactiveerd, moet het rapport zeggen welk adres is gelezen, hoeveel berichten erin zaten en welke onderwerpen ze hadden. Zonder dat draait de volgende persoon de pipeline opnieuw in plaats van hem te diagnosticeren.
Parse defensief. Neem de nieuwste overeenkomst op de ontvanger en het verwachte onderwerp, en extraheer dan de code uit de context eromheen. Als er geen code wordt gevonden, faal dan met de body in plaats van met een generieke timeout.
Schakel nooit een limiet uit om een test te laten slagen. De limiet is deel van het gedrag dat wordt getest, en een suite die hem uitzet beschrijft niet langer het product dat je gebruikers tegenkomen. Ga in plaats daarvan met de limiet om: kies een adres dat recent niet is gebruikt, en lees het bestaande bericht in plaats van een nieuw aan te vragen.
Houd het menselijke pad in leven. Documenteer voor de gevallen waarin automatisering de code echt niet kan lezen de handmatige stap en maak die zichtbaar in de uitvoer van de run, zodat een overgeslagen controle nooit wordt aangezien voor een geslaagde.
Het artikel over flowtesten voor verificatie behandelt de flow rond de code, en hoe tijdelijke mail werkt legt uit waarom een traag of gedupliceerd bericht normaal is en niet kapot.
Volgende stappen
Zoek de codestap in je suite en controleer de twee dingen die het vaakst ontbreken: of het adres uniek is voor het geval, en of het faalbericht iemand anders in staat stelt de run te diagnosticeren zonder hem te herhalen. Voer daarna hetzelfde geval uit met een adres dat vers is aangemaakt via de tijdelijke mailpagina en kijk of de onbetrouwbaarheid die je tolereerde verdwijnt.