Blog
Je kan er bijna niet aan ontkomen: waar software gemaakt wordt, worden tests geschreven. Deze tests verkleinen de kans op een bug. Er zijn echter vele soorten en smaken tests die uitgevoerd kunnen worden. Maar hoe besluit een ontwikkelaar welke tests hij allemaal uit moet voeren?
Partijen die software maken, moeten een koers kiezen waarbij zij met de kleinste investering van tijd, de hoogst mogelijke kwaliteit software kunnen waarborgen. Er zijn veel manieren om te testen of je software correct functioneert en daarmee voldoet aan de vereisten en voorwaarden van de dienst.
Een kleine greep uit het scala aan software tests:
Regressietests – het testen of niet-aangepaste onderdelen van de applicatie nog werken.
Acceptatietests – het testen of opgeleverde software correct werkt.
Smoketests – steekproefsgewijs testen, met in het achterhoofd: waar rook is, is vuur.
Bug hunten – gedurende een vast tijdsblok proberen om een fout in de software te forceren.
Integratietests – het in een groep met elkaar communicerende softwaresystemen testen.
Unit tests – het testen van kleine stukjes logica.
In onze ogen is de unit test een essentieel onderdeel van het ontwikkelproces, die alleen door de ontwikkelaar zelf geschreven en uitgevoerd kan worden. In dit blog willen wij wat dieper ingaan op hoe wij bij WebFlight met unit tests omgaan.
Met een unit test wordt onderzocht of de ontwikkelde software daadwerkelijk doet waarvoor het gemaakt is. Met deze methode kunnen kleine, losse stukjes logica (units) onafhankelijk van elkaar, snel en grondig getest worden. Bij het opstellen van een unit test stop je bepaalde gegevens in je logica en stel je een aantal verwachte uitkomsten op. De gegevens die je erin stopt, moeten zoveel mogelijk uiteenlopen, dus zowel correcte als incorrecte invoer. De daadwerkelijke uitkomst vergelijk je vervolgens met de verwachte uitkomst, zodat je weet of je logica klopt.
Bij het opstellen van unit tests is het goed om je te houden aan het FIRST principe. FIRST staat voor Fast, Isolated, Repeatable, Self-validating, Thorough:
Fast: Het is belangrijk dat de unit test snel is. Je wil immers niet elke keer minuten of uren wachten voordat deze is afgerond.
Isolated: De unit test moet geïsoleerd en onafhankelijk van andere logica uit te voeren zijn.
Repeatable: Daarnaast moet na het uitvoeren van een test, steeds hetzelfde resultaat volgen.
Self-validating: De unit test moet zichzelf valideren. Dat wil zeggen: er moet goed of fout uitkomen. Je wilt niet na iedere test handmatig moeten controleren of het resultaat klopt.
Thorough: De unit test moet grondig zijn. Wij doen dit door alle paden die de logica kan volgen te testen. Je bereikt daarmee een hoge zogeheten test dekking.
Om kwalitatief hoogwaardige software af te leveren en dit op een zo betrouwbaar mogelijke manier te doen, is de unit test een onmisbaar middel. Wanneer een aanpassing in de software wordt gedaan, kan een unit test ervoor zorgen dat eventuele ongewenste effecten snel opgespoord kunnen worden. Daarnaast dwingt het je om nog een keer grondig je logica te bekijken voordat je deze oplevert. Eventuele crashes, zoals een ‘nul pointer’ waarbij je verwijst naar niet-bestaande objecten, komen hier zeer waarschijnlijk aan het licht.
Een voorbeeld van een ware IT-ramp die voorkomen had kunnen worden, is de crash van de Mars Climate Orbiter eind jaren ’90. Deze onbemande ruimtesonde zou in een baan rond Mars het klimaat, de atmosfeer en het oppervlak van de planeet gaan bestuderen. Door een menselijke fout, waarbij eenheden uit het ‘Imperial Standard System’ werden gebruikt in plaats van het gebruikelijke metrieke stelsel, vloog de sonde te laag de atmosfeer van Mars binnen, waardoor deze verloren ging. Zonde. Een simpele unit test had deze ontwikkelfout vroeg in het proces kunnen opsporen. Nu houden wij ons bij Webflight niet bezig met spaceflight, dus zal een fout met zulke desastreuze gevolgen bij ons niet snel plaatsvinden. Maar toch is het fijn om te weten dat jouw sondes bij ons veilig blijven.
Veel softwarebedrijven kiezen ervoor om geen unit tests te doen, omdat het in eerste instantie meer tijd kost om de software te ontwikkelen. Echter betaalt deze relatief kleine tijdsinvestering zich ontzettend snel uit. Die ene bug die normaal ongezien naar de productieserver zou gaan, is er nu namelijk op voorhand al uitgehaald. Zeker in applicaties die door klanten worden gebruikt, kan grondig testen gezichtsverlies voorkomen. Daarom zou elke opdrachtgever het toepassen van unit tests in overweging moeten nemen bij het kiezen van een applicatiebouwer. Voorkomen is beter dan genezen.
Ben je geïnteresseerd in een unit test en hoe je je bedrijfssoftware kan verbeteren? Neem dan contact met ons op voor een expert review.