Test engineering, Testautomatisering, Tooling

In een Continuous Delivery pipeline is het een good-practice om gebruik te maken van smoke testen die automatisch worden uitgevoerd na een deployment. Op deze manier kan worden aangetoond dat de deployment succesvol is verlopen en dat een applicatie of service up-and-running is. Bij smoke testing gaat het om het uitvoeren van lichte (ofwel shallow) testen voor het beantwoorden van elementaire vragen zoals ‘kan de applicatie opstarten?’, ‘is een service of API beschikbaar?’ en ‘kunnen alle componenten met elkaar communiceren?’. Deze testen moeten zeer snel antwoord geven – en dus een korte executie tijd hebben – aangezien deze testen bij iedere deployment zullen draaien, zowel in de ontwikkel, staging en productie omgevingen. Wanneer een smoke test mislukt toont het aan dat er iets fundamenteels mis is en dat verder testen geen zin heeft. Vandaag de dag werken we veel met web-applicaties en vanuit dat perspectief wil je controleren of de web-front-end opstart en correct kan communiceren met de web-front-back-end en de backend.

Natuurlijk kan WebDriver worden gebruikt om een ​​smoke test te maken. We creëren eenvoudig een aantal testen aan de hand van een functioneel klik pad en kunnen daarmee bevestigen of bepaalde gegevens zichtbaar zijn op de webpagina. Deze gegevens worden vanuit de backend opgehaald en door te bevestigen welke gegevens we daadwerkelijk ‘zien’ op de pagina, bewijzen we dat de hele keten van componenten operationeel is. WebDriver is geweldig om toegang te krijgen tot de HTML DOM om een functionele geautomatiseerde tests uit te voeren, maar vanuit het perspectief van smoke testen kun je je afvragen of dit de meest efficiënte manier is. Om dit te laten werken hebben we een (headless) webbrowser nodig die geïnstalleerd is op een testagent. Dit vereist extra infrastructuur. Omdat we alleen geïnteresseerd zijn in een antwoord en niet in een exact antwoord hebben we de HTML DOM helemaal niet nodig voor smoke testen. Daarnaast zijn UI-testen kwetsbaar, nemen ze – relatief – veel tijd in beslag om uit te voeren en deze testen zullen regelmatig aan wijzigingen onderhevig zijn. Wat als we dit veel makkelijker en sneller kunnen testen zonder extra infrastructuur en met minder onderhoud?

In een .NET-omgeving kunnen we smoke testen maken met het MStest-framework die de WebClient-class gebruikt. WebClient biedt standaardmethoden voor het verzenden en ontvangen van gegevens uit een door een URI geïdentificeerde bron. We voeren deze Smoke testen uit door HTTP GET- en HTTP POST-opdrachten uit te voeren en dus niet door een directe interactie met de HTML DOM zoals een webbrowser doet. Door interactie te zoeken op een lager niveau zijn de tests veel sneller, betrouwbaarder en kunnen ze direct het juiste bewijzen. Ze zijn deterministischer dan UI testen.

180309 – Het snel en efficiënt uitvoeren van smoke testen met behulp van WebClient in – 1 van 6

Met de bovenstaande code ontvangen we de HTML-paginabron van ‘http://www.google.com’ en kunnen we controleren of de string htmlDocument een bepaald woord of zin bevat. We kunnen gegevens downloaden met de DownloadString-methode (GET) en gegevens uploaden met verschillende uploadmethoden (POST).  Dit werkt leuk voor simpele webpagina’s maar zodra we praten over sessies werkt dit niet meer.  De WebClient class bevat geen manier om cookies bij te houden en is daarom niet sessiebewust. We moeten de GetWebRequest-methode overschrijven door een aangepaste WebClient-klasse WebSession te maken:

180309 – Het snel en efficiënt uitvoeren van smoke testen met behulp van WebClient in – 2 van 6

In de bovenstaande code voorzien we onze WebSession class sessie van een CookieContainer die ervoor zorgt dat de informatie over de sessie wordt vastgehouden. Met deze CookieContainer kunnen we een POST-opdracht uitvoeren met onze inloggegevens:

180309 – Het snel en efficiënt uitvoeren van smoke testen met behulp van WebClient in – 3 van 6

Nu we een relevante sessie hebben naar ons systeem kunnen we controleren of gegevens correct worden geretourneerd. Om dit te bewijzen heb ik verschillende methoden gecreëerd:

IsPageAvailable om te checken of een Uri beschikbaar is en een HTTP OK (200) status code retourneert:

180309 – Het snel en efficiënt uitvoeren van smoke testen met behulp van WebClient in – 4 van 6

IsUriReturningValidJSON om te checken of een Uri geldige JSON terugstuurt. Ik gebruik de NewtonSoft JSON NuGet package om de string value naar een JSON-token te parsen:

180309 – Het snel en efficiënt uitvoeren van smoke testen met behulp van WebClient in – 5 van 6

Nu kunnen we onze smoke testen opstellen:

180309 – Het snel en efficiënt uitvoeren van smoke testen met behulp van WebClient in – 6 van 6

Met deze code hebben we snelle, betrouwbare smoke testen gecreëerd die meteen de sweet spot raken.  De ms-test assembly kunnen we vervolgens opnemen in de VSTS release pipelines door de ‘Visual Studio test’ task toe te voegen. Door middel van testcategories zijn de testen te sturen en door runsettings is de configuratie aanpasbaar.

Happy smoke testing!

Schrijf je in voor
de nieuwsbrief

werkenbij overall

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz