End-to-end testen van je API, van inloggen tot de laatste controle

Wat end-to-end testen van een API inhoudt

Een end-to-end test roept je backend aan zoals een client dat doet, en laat elke laag zijn werk doen: de gateway, de authenticatie, de services, de database, de achtergrondtaken. Binnen het geteste systeem wordt niets nagebootst. Dat maakt zo’n test waardevol, en ook traag en kwetsbaar als je hem slordig opzet.

Vergeleken met tests via de browser zijn end-to-end tests op de API sneller en stabieler, en ze testen de regels die er het meest toe doen: wie mag wat. Hoe de schermen eruitzien, testen ze niet.

Log in zoals je gebruikers

De meest gemaakte shortcut is ook de duurste: testen met één servicetoken dat alles mag. Zulke tests vinden geen toegangsfouten, en ze slaan het inloggen over, juist de stap die het vaakst zichtbaar breekt.

• Gebruik per rol een testaccount, met de echte rechten en de echte organisatie van die rol.
• Log in zoals die rol dat doet: OAuth of OpenID Connect, een inlogformulier met CSRF-token, single sign-on, een tweede factor.
• Houd wachtwoorden en tokens buiten de testcode en buiten de resultaten.
• Ververs tokens zoals de client dat doet, zodat problemen met verlopen tokens in de test opduiken en niet in productie.

Testdata en omgevingen

• Maak aan, leen niet. Elke run maakt de records die hij nodig heeft, met unieke namen, en ruimt ze aan het eind op.
• Alleen lezen op productie. Journeys die alleen lezen kunnen op productie draaien; journeys die schrijven horen op test en acceptatie.
• Eén definitie, meerdere omgevingen. Dezelfde test draait op test, acceptatie en productie; alleen het adres en de accounts verschillen.
• Een mock voor wat er nog niet is. Zolang de backend nog niet bestaat, laat een mock op basis van het contract de frontend en de tests alvast beginnen.

In de pijplijn en daarna

1. Draai na elke deploy een kleine set, en houd de release tegen of markeer hem als die faalt.

2. Draai de belangrijkste journeys op een interval, zodat ook fouten door data, configuratie of een afhankelijkheid boven komen.

3. Waarschuw één keer als een journey begint te falen, en één keer als hij hersteld is; een melding bij elke mislukte run wordt genegeerd.

4. Bewaar de geschiedenis met tijden, zodat je ziet wanneer het traag werd, niet alleen wanneer het brak.

End-to-end testen met Journey Lanes

Journey Lanes maakt flows op basis van je code en draait ze tegen een mock-backend of je eigen omgevingen. Elke omgeving heeft een API-adres, een manier van inloggen met presets voor gangbare identity providers, en per rol een testaccount. Schrijven en loadtests staan uit tot je ze toestaat.

Deploy checks draaien gekozen flows na elke deploy vanuit elke CI, met een GitHub commit status (CI en exports). Monitoring herhaalt ze op een interval, met één melding als ze falen en één als ze hersteld zijn (monitoring).