API-rooktests uitvoeren in je continue implementatiepijplijn
Elk jaar stappen meer softwarebedrijven over op een microservicesarchitectuur met behulp van Application Programming Interfaces (API's), omdat API's het eenvoudig maken voor verschillende teams binnen een project om elkaars bronnen te gebruiken. API's stellen softwarebedrijven of individuen ook in staat om gegevens van elkaar op te halen: Twitter heeft bijvoorbeeld een API die door veel kleine bedrijven wordt gebruikt om tweets over hun bedrijf op te halen en op de webpagina van het bedrijf weer te geven.
Een andere geweldige eigenschap van API's is dat ze kleiner zijn dan een monolithische applicatie, wat betekent dat ze regelmatig kunnen worden geïmplementeerd. Bij het bedrijf waar ik werk heeft elk team meerdere API's en hebben we acht verschillende omgevingen waarnaar we implementeren. Als we uitsluitend zouden vertrouwen op handmatig testen om te controleren of de API's correct waren geïmplementeerd, zouden we voor elke API-release acht testsets moeten uitvoeren. En als we meer dan één API tegelijk zouden implementeren, wat we vaak doen omdat onze API's samenwerken, zouden we honderden tests kunnen uitvoeren. En als we elke twee weken implementeren, zouden die tests neerkomen op heel wat vervelend, repetitief testwerk!
We hebben dit probleem opgelost door geautomatiseerde API-smoketests in te stellen die bij elke implementatie naar elke omgeving worden uitgevoerd. In dit artikel beschrijf ik hoe we hebben besloten wat we moesten testen en hoe we onze smoketests hebben opgezet. We gebruikten Postman, Newman, Powershell en Octopus om onze geautomatiseerde smoketests op te zetten, dus ik beschrijf wat we met die hulpmiddelen hebben gedaan. Deze strategieën kunnen echter worden toegepast op elke pijplijn voor continue implementatie (CD).
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Stap één: Bepaal wat je moet testen
Het belangrijkste doel van smoketests is om enkele eenvoudige tests op hoog niveau uit te voeren om te controleren of de implementatie is geslaagd. Dit is niet de plek om alles te testen wat je API kan doen. Bij het bepalen wat we in onze smoketests moesten opnemen, hebben we het volgende overwogen:
- We hebben voor elk eindpunt één test voor het “succespad” ingesteld — dat wil zeggen: één test waarvan wordt verwacht dat die succesvol is. Zo zou een GET-verzoek voor een bron met een specifieke ID naar verwachting die bron moeten retourneren. Je wilt elk eindpunt één keer testen om te controleren of het werkt zoals verwacht.
- Als er grote variaties waren in de manier waarop een specifiek eindpunt zou worden gebruikt, voegden we één of meer tests toe om die variaties te controleren. We hebben bijvoorbeeld een API voor het ophalen van bestanden waarbij een bestand op twee verschillende manieren kan worden opgehaald. Het eindpunt ziet er hetzelfde uit, maar de aanvraagteksten verschillen. Daarom voegden we voor elke methode één test toe.
- Voor eindpunten waarvoor een bepaald beveiligingsniveau vereist was, voegden we een test toe om te controleren dat een verzoek zonder de juiste verificatie GEEN informatie zou retourneren, maar in plaats daarvan een fout op 400-niveau zou opleveren.
- We hebben geen andere negatieve tests toegevoegd, zoals een POST-verzoek met gegevens buiten de toegestane parameters, omdat we niet vonden dat die nodig waren om te controleren of de API werkte. In plaats daarvan voerden we die tests uit als onderdeel van een nachtelijke regressietestsuite.
Stap twee: Exporteer je tests
We gebruikten Postman om onze API-tests te maken. Toen de tests waren aangemaakt, exporteerden we zowel de testverzameling als het testomgevingsbestand naar JSON-bestanden. Voor degenen die niet bekend zijn met Postman: een testomgeving is een groep variabelen waarnaar in een verzameling tests kan worden verwezen.
Stap drie: Schrijf een script om je tests uit te voeren
Postman heeft een opdrachtregelprogramma met de naam Newman, dat kan worden gebruikt om een testverzameling uit te voeren. Daarom gebruikten wij dit om onze tests uit te voeren. We maakten een Powershell-script dat de opdracht van Newman zou uitvoeren.
Stap vier: Maak een implementatiestap om je script aan te roepen
Toen het Powershell-script klaar was, stelden we in elk Octopus-implementatieproject voor API's een implementatiestap in die het testscript zou uitvoeren. Als het script mislukte, mislukte de implementatie.
Stap vijf: Orden je variabelen
Variabelen zijn vaak een aandachtspunt bij het uitvoeren van smoketests in verschillende omgevingen. In je QA-omgeving kan je testgebruiker bijvoorbeeld de ID 340 hebben, terwijl je testgebruiker in je Staging-omgeving de ID 620 kan hebben. Een ander probleem met variabelen is dat je om veiligheidsredenen soms geen toegang hebt tot wachtwoorden of sleutels in productieomgevingen. Dat was bij ons team het geval, maar gelukkig bevat Octopus de waarden die we nodig hebben om onze tests in Productie uit te voeren. We losten het probleem daarom op door Octopus de benodigde waarden aan ons testscript te laten doorgeven.
Voor onze smoketest waren drie verschillende soorten variabelen nodig:
- Type 1: Variabelen die voor elke testomgeving onveranderd bleven, zoals “firstName”: “Prunella”. Deze variabelen konden rechtstreeks in de Postman-omgeving worden geplaatst, dus verder hoefde er niets mee te gebeuren.
- Type 2: Variabelen die per testomgeving veranderden, maar niet geheim hoefden te blijven, zoals “userId”: 340. Deze variabelen werden als volgt toegevoegd als Octopus-variabelen: “smoke.userId”. De waarde van de variabele werd voor elke omgeving ingesteld; QA werd bijvoorbeeld ingesteld op 340, Staging op 620 en Productie op 450.
- Type 3: Variabelen die voor elke testomgeving veranderden en veilig moesten worden bewaard, zoals “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Type 3-variabelen waren al ingesteld in de variabelenbibliotheek van Octopus.
We gebruikten de variabelen vervolgens als volgt:
- Toen we het Powershell-script in Octopus aanriepen, stuurden we de in Octopus ingestelde variabelen naar het script.
- In het Powershell-script accepteerden we de meegestuurde Octopus-variabelen en wezen we deze toe aan Powershell-variabelen.
- Toen we de Newman-opdracht in het Powershell-script gebruikten, stuurden we de variabelen in het script naar de Postman-omgeving.
- Newman gebruikte de variabelen die in het Powershell-script waren meegestuurd, gecombineerd met de variabelen in de Postman-omgeving, om de Postman-verzameling uit te voeren.
Nu onze API-basistests in Octopus voor elke API en in elke omgeving worden uitgevoerd, kunnen we erop vertrouwen dat eventuele grote problemen met een API-implementatie onmiddellijk worden ontdekt. Bovendien kunnen we testen in productieomgevingen, zelfs als we geen toegang hebben tot gevoelige API-sleutels. Dankzij automatische basistests voor implementaties kunnen we andere soorten tests uitvoeren, zoals handmatig verkennend testen en beveiligingstesten, en meer testautomatisering schrijven voor nachtelijke regressietests.
Abonneer je op de nieuwsbrief van The QA Lead voor meer handleidingen.
Blijf leren en beluister deze podcast: HOE OPEN-SOURCESOFTWARE INTEGRATIE IN AUTOMATISERINGSTECHNIEK VEREENVOUDIGT (MET JAMES WALKER EN SANJAY KUMAR)
