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.