Test React-uitnodigingsmails zonder inbox-botsingen
Preview-omgevingen falen wanneer uitnodigingsflows een gedeelde QA-inbox overspoelen.
De ene tester opent de verkeerde link. Een ander pakt een oud bericht. Het team discussieert of de React-code kapot is of dat de backend oude gegevens heeft verzonden.
Je moet de mailbox als onderdeel van je product beschouwen. Als je onboarding afhankelijk is van e-mail, hebben je preview-omgevingen een isolatiestrategie nodig. Zonder die strategie vertraagt je feedbackloop.
Veelvoorkomende foutmodi in preview-branches:
- De e-maillink verwijst naar een oude deployment.
- Opnieuw uitgevoerde API-aanroepen creëren twee uitnodigingen voor één gebruiker.
- De UI accepteert de uitnodiging, maar toont oude lidmaatschapsgegevens.
- Eén tester gebruikt de token voordat iemand anders de branch valideert.
Gedeelde inboxes zorgen voor onbetrouwbare tests en een laag vertrouwen.
Gebruik dit eenvoudige proces om het op te lossen:
- Maak de uitnodiging aan via het echte React-beheerscherm in de preview-omgeving.
- Gebruik hetzelfde backend-pad, dezelfde templates en dezelfde token-logica als in productie.
- Leid het bericht naar een kortstondige inbox die alleen voor die specifieke run is aangemaakt.
- Open de link in een browser en controleer de status van de app.
Disposable e-mailgenerators werken goed voor snelle branch-validatie. Ze houden je flow eenvoudig.
Een goede preview-test moet de volgende zaken controleren:
- De e-mail bevat de juiste preview-host voor die branch.
- Er bestaat slechts één actieve uitnodigingslink voor de ontvanger.
- De token leidt naar de juiste workspace en rol.
- De React-app werkt de toegangsstatus bij zonder handmatige reload.
- Het klikken op de link voor een tweede keer mislukt na acceptatie.
Vergeet de frontend-assertie niet. Backend-logs kunnen succes aangeven, terwijl de client nog steeds een 'pending' status toont. Gebruikers merken dit direct op.
Het toevoegen van een correlation ID, van de aanmaak van de uitnodiging tot de uiteindelijke activatie, bespaart tijd. Het helpt je te achterhalen of de verkeerde host in een template is geslopen door omgevingsvariabelen.
Het doel is niet om overal disposable inboxes te gebruiken. Het doel is om het realistische uitnodigingspad te isoleren. Dit vangt regressies op voordat ze in productie terechtkomen.
Gebruik deze checklist voordat je een wijziging in de uitnodigingsflow vertrouwt:
- De e-mail linkt naar de juiste preview-deployment.
- De token koppelt aan de juiste workspace en rol.
- Een tweede klik hergebruikt niet dezelfde token.
- De geaccepteerde status verschijnt in de UI zonder extra navigatie.
- De mailbox is gemakkelijk te identificeren en te verwijderen.