In dit artikel gaan we de voordelen van het schrijven van geautomatiseerde tests vanuit het perspectief van een ontwikkelaar verkennen. Dit zal niet alleen nuttig zijn voor ontwikkelaars die misschien nog niet overtuigd zijn van de waarde van geautomatiseerd testen, maar het zal ook inzicht bieden voor producteigenaars die willen bepalen of ze deze praktijk willen opnemen in hun applicaties.

Testing leads to failure, and failure leads to understanding. — Burt Rutan

Voordat we ingaan op de voordelen van geautomatiseerd testen, is het belangrijk om vast te stellen wanneer het wel en niet gepast is om tests te schrijven. Hoewel geautomatiseerd testen een waardevol hulpmiddel kan zijn, is het mogelijk niet noodzakelijk of praktisch voor elke situatie. Zo is het bijvoorbeeld misschien niet nodig om volledige geautomatiseerde tests te schrijven voor een eenvoudige WordPress-website voor familiefotoalbums.

Er zijn voornamelijk drie factoren die bepalen of tests nuttig zijn:

1. Toepassingen met een hoog niveau van complexiteit.

2. Toepassingen die een cruciale rol vervullen en niet mogen falen.

3. Toepassingen waar grote teams aan werken.

Hoe meer van deze 3 factoren van toepassing zijn, hoe verstandiger het is om tests te maken. Maak je geen zorgen, jouw WordPress-website heeft waarschijnlijk geen van deze factoren.

Terminologie

Code bestaat uit meerdere samenwerkende onderdelen. In de meeste talen worden die onderdelen objecten genoemd. Ik zal daar in dit artikel bij blijven.

Testdekking. Dit is het percentage code dat wordt getest door geautomatiseerde tests.

Wat is een geautomatiseerde test?

Als je al bekend bent met geautomatiseerde tests, voel je vrij om deze sectie over te slaan.

In softwareontwikkeling heeft elk object een specifieke verantwoordelijkheid en dient het een specifiek doel. Laten we bijvoorbeeld zeggen dat we een object hebben dat is ontworpen om te bepalen of een getal gelijkmatig kan worden verdeeld door 2. Een manier om ervoor te zorgen dat dit object correct functioneert, is door een geautomatiseerde test te maken die het vragen stelt en de antwoorden verifieert. Op deze manier kunnen we erop vertrouwen dat het object het probleem oplost waarvoor het is ontworpen en presteert zoals verwacht.

• Is 0 deelbaar door 2? Verwacht antwoord nee.

• Is 1 deelbaar door 2? Verwacht antwoord nee.

• Is 2 deelbaar door 2? Verwacht antwoord ja.

• Is 3 deelbaar door 2? Verwacht antwoord nee.

Applicaties bestaan vaak uit duizenden objecten, en geautomatiseerd testen kan helpen ervoor te zorgen dat al deze objecten zoals bedoeld functioneren.

Er zijn twee soorten geautomatiseerde tests. Unit tests, die een enkel object testen, en feature tests, die meerdere objecten samen testen. Beide soorten tests hebben hun eigen voor- en nadelen, en welke het meest geschikt is, hangt af van wat er getest moet worden. De meeste projecten hebben beide.

Met dit in gedachten, laat me de belangrijkste redenen delen waarom ik de voorkeur geef aan geautomatiseerde tests.

Testresultaten van een test die valideert wanneer een winkelwagentje mag afrekenen.

Heb ik iets kapotgemaakt?

Een grote applicatie heeft veel objecten, en al deze objecten interacteren met elkaar en worden veelvuldig door elkaar opnieuw gebruikt. Wanneer een ontwikkelaar een object bijwerkt, is het moeilijk en soms onmogelijk om alle plaatsen en redenen te begrijpen waarom en waar dat object wordt gebruikt.

Dus wanneer een ontwikkelaar het object wijzigt voor een nieuwe functie, probeert hij/zij ook bestaande functies werkend te houden. Maar hoe groter het systeem, hoe moeilijker het is om dit te begrijpen.

Als elke ontwikkelaar die iets wijzigt ook nieuwe tests levert, en bestaande tests bijwerkt, voor die wijziging, kunnen alle vereisten voor dat object binnen enkele seconden worden gevalideerd.

Test die mislukt omdat een wijziging een bug heeft geïntroduceerd

Handmatig kost meer tijd

Stel je een winkelwagentje voor in een webwinkel waar een ontwikkelaar de manier moet wijzigen waarop kortingen worden berekend. Wanneer dit is gedaan, heeft de ontwikkelaar slechts één manier om te bepalen of alle scenario's nog steeds werken. Hij/zij moet het winkelwagentje vullen met alle verschillende soorten producten en kortingen die het systeem ondersteunt. Dat is veel, en tijdens dat proces hoop je dat de ontwikkelaar geen fout maakt bij het valideren van de totaalprijs onderaan. Daarna moet de ontwikkelaar dat herhalen op de bestelpagina, de factuur en waarschijnlijk nog meer locaties. Dit kost tijd.

Als er tests aanwezig zijn voor al deze situaties, kan de ontwikkelaar ze eenvoudig uitvoeren en valideren binnen 1 minuut.

Het is documentatie

In de meeste gevallen, als een systeem gedocumenteerd is, betekent dit dat iemand aan het begin van het project een document heeft geschreven met een set eisen die na de eerste periode nooit meer wordt gelezen. Documentatie is altijd (of 99,9% van de tijd) verouderd en kan meerdere interpretaties hebben.

Goede tests zijn geen onleesbare abstracte stukken machinetaal. Ze hebben namen en kunnen worden gelezen als kleine verhalen. Ze kunnen dienen als documentatie, en documentatie in de vorm van tests kan niet worden overgeslagen vanwege deadlines of eenvoudige luiheid.

Het gebruik van tests als documentatie voor ontwikkelaars / door ontwikkelaars

Tests dwingen je om na te denken

Ooit gehoord van "rubber duck programming"? Dit is een praktijk die ontwikkelaars toepassen wanneer ze geen oplossing kunnen vinden voor iets of een bug kunnen vinden. Ze plaatsen een gele rubberen eend op hun bureau en beginnen het probleem aan de eend uit te leggen. Dit dwingt hen om een helicopterview van het probleem te nemen en de code opnieuw te evalueren. Dit denkproces onthult vaak het probleem waar ze mee worstelen.

Je kunt het altijd aan de eend uitleggen

Bij het schrijven van tests worden ontwikkelaars gedwongen op dezelfde manier te denken als tijdens sessies waarin ze het probleem aan de rubberen eend uitleggen. Dit resulteert in een breder begrip van het proces en het ontdekken van aspecten waar niemand eerder aan heeft gedacht. Dit kan soms de reikwijdte van de vereiste vergroten, maar het is beter om dit binnen je ontwikkelingsproces te hebben dan nadat de nieuwe functie live is gegaan.

Nieuwe ontwikkelaar

Als laatste, maar nog steeds belangrijk… Wanneer je gigantisch complexe applicatie al een lange tijd in productie draait, laten we zeggen 3 of 4 jaar. Besluiten 2 van je belangrijkste ontwikkelaars (die alles weten van het systeem) om te vertrekken en heb je het geluk om tijdig vervanging te vinden.

De kans dat ze 10 nieuwe bugs introduceren voor elke functie die ze toevoegen of bijwerken is gigantisch. Ervaren ontwikkelaars zullen iets minder bugs introduceren, maar ze zullen ze nog steeds toevoegen. Ze zijn te onbekend met je applicatie. Voor hen is het onmogelijk om 100% van de gevolgen van sommige wijzigingen die ze moeten doen, te begrijpen.

Een goede testdekking kan het risico op het introduceren van bugs bij het bijwerken van objecten in een grote applicatie aanzienlijk verminderen. Geautomatiseerde tests kunnen ontwikkelaars informeren over eventuele problemen die kunnen ontstaan als gevolg van hun wijzigingen, waardoor ze deze problemen kunnen oplossen voordat de update wordt vrijgegeven. Dit kan zowel ontwikkelaars als producteigenaars gemoedsrust bieden, omdat het ervoor zorgt dat de applicatie stabiel en betrouwbaar is na elke update.

Samenvatten

Ik hoop dat dit artikel je extra kennis heeft gegeven over de voordelen van het hebben van geautomatiseerde tests, zodat je betere beslissingen kunt nemen als dat nodig is.

Elk van de punten die ik in dit artikel heb besproken, is het resultaat van de ervaringen die ik heb opgedaan met het testen van de projecten waar ik aan heb gewerkt. Dit is geen artikel waarom je TDD zou moeten doen (ik schrijf bijna nooit mijn tests vooraf, meestal ergens halverwege het proces). En ik beloof ook geen bugvrij project.

Het is praktische kennis die je kunt gebruiken om het proces van het ontwikkelen van complexe applicaties te verbeteren.

Ben je een Laravel-ontwikkelaar en nieuw met testen? Hier zijn enkele goede bronnen om mee te beginnen:

• Laravel Testing For Beginners: PHPUnit, Pest, TDD

• Laracasts Category: Testing