Wat is geautomatiseerd testen?
In deze les krijgt u informatie over de voordelen van geautomatiseerde tests en de soorten tests die u kunt uitvoeren. U leert ook wat een goede test maakt en kennis maakt met enkele van de testhulpprogramma's die voor u beschikbaar zijn.
Wat is geautomatiseerd testen?
Geautomatiseerde tests maken gebruik van software om uw code uit te voeren en de werkelijke resultaten te vergelijken met de resultaten die u verwacht. Vergelijk dit met verkennende of handmatige tests, waarbij een mens doorgaans instructies in een testplan volgt om te controleren of software naar verwachting functioneert.
Handmatig testen heeft de voordelen. Maar naarmate uw codebasis groter wordt, kan het handmatig testen van alle functies (inclusief edge-cases) herhaaldelijk, tijdrovend en foutgevoelig worden. Met geautomatiseerde tests kunnen sommige van deze lasten worden weggenomen en kunnen handmatige testers zich richten op wat ze het beste doen: ervoor zorgen dat uw gebruikers een positieve ervaring met uw software hebben.
De test piramide
Wanneer we nadenken over geautomatiseerde tests, is het gebruikelijk om tests te scheiden in lagen. Mike Cohn stelt dit concept voor, bekend als de test piramide, in zijn boek Succeeding with Agile.
Hoewel dit een simplistische versie van Het model van Cohn is, illustreert het concept dat u zich vooral richt op het schrijven van tests die de basisniveaus van uw software verifiëren (bijschrift 1 in de piramide), zoals functies, klassen en methoden. U richt zich geleidelijk minder op omdat functies worden gecombineerd, zoals op de gebruikersinterfacelaag (UI) (bijschrift 2 in de piramide). Het idee is dat als u kunt controleren of elk onderdeel op een lager niveau werkt zoals verwacht, tests op de hogere niveaus alleen hoeven te controleren of meerdere onderdelen samenwerken om het verwachte resultaat te verkrijgen.
Wanneer moet ik tests schrijven?
Het antwoord hangt voornamelijk af van uw behoeften en ervaring bij het schrijven van tests.
Het is nooit te laat om te beginnen met het toevoegen van tests voor code die u al hebt geschreven en geïmplementeerd. Dit geldt met name voor functies die vaak breken of de meeste inspanning van uw testteam vereisen.
Wanneer u tests koppelt aan continue integratie en pijplijnen voor continue levering, horen twee concepten waarover u doorlopende tests uitvoert en naar links verschuift.
Doorlopend testen betekent dat tests vroeg in het ontwikkelingsproces worden uitgevoerd wanneer elke wijziging door de pijplijn loopt. Overschakelen betekent dat u eerder in het ontwikkelingsproces rekening houdt met softwarekwaliteit en -tests.
Ontwikkelaars voegen bijvoorbeeld vaak testcases toe tijdens het ontwikkelen van hun functie en voeren de hele reeks tests uit voordat ze de wijziging indienen bij de pijplijn. Deze aanpak zorgt ervoor dat de functie die ze bouwen zich gedraagt zoals verwacht en dat de bestaande functies niet worden onderbroken.
Hier volgt een korte video waarin Abel Wang, Cloud Advocate bij Microsoft, uitlegt hoe u ervoor kunt zorgen dat u de kwaliteit in uw DevOps-plan behoudt.
Vraag het aan Abel
Als u naar links schuift, moeten testers vaak betrokken raken bij het ontwerpproces, zelfs voordat code voor de functie wordt geschreven. Vergelijk dit met het 'handoff'-model, waarbij het testteam nieuwe functies krijgt om alleen te testen nadat de software is ontworpen en geschreven. Een fout die te laat in het proces is ontdekt, kan van invloed zijn op het leveringsschema van het team en fouten kunnen weken of zelfs maanden nadat de ontwikkelaar de functie heeft gebouwd, worden gedetecteerd.
Het compromis
Met geautomatiseerd testen is er een compromis. Hoewel met geautomatiseerd testen testers hun tijd kunnen richten op het verifiëren van de eindgebruikerservaring, moeten ontwikkelaars mogelijk meer tijd besteden aan het schrijven en onderhouden van hun testcode.
Het punt van geautomatiseerd testen is echter om ervoor te zorgen dat testers alleen de code van de hoogste kwaliteit ontvangen, code die naar verwachting functioneert. Daarom kunnen ontwikkelaars een deel van hun tijd vrijmaken door minder bugs af te handelen of om herschrijven van code te voorkomen vanwege een edge-case die ze oorspronkelijk niet hadden overwogen.
Toegevoegde voordelen
Documentatie en de mogelijkheid om uw code gemakkelijker te herstructureren, zijn twee extra voordelen van geautomatiseerd testen.
Documentatie
Handmatige testplannen kunnen fungeren als een soort documentatie over hoe software zich moet gedragen en waarom bepaalde functies bestaan.
Geautomatiseerde tests kunnen hetzelfde doel dienen. Geautomatiseerde testcode maakt vaak gebruik van een door mensen leesbare indeling. De set invoer die u opgeeft, vertegenwoordigt waarden die uw gebruikers kunnen invoeren. Elke gekoppelde uitvoer geeft het resultaat aan dat uw gebruikers moeten verwachten.
In feite volgen veel ontwikkelaars de testgestuurde ontwikkelingsmethode (TDD) door hun testcode te schrijven voordat ze een nieuwe functie implementeren. Het idee is om een reeks tests, ook wel specificaties genoemd, te schrijven die in eerste instantie mislukken. Vervolgens schrijft de ontwikkelaar stapsgewijs code om de functie te implementeren totdat alle tests zijn geslaagd. Niet alleen documenteren de specificaties de vereisten, maar het TDD-proces helpt ervoor te zorgen dat alleen de benodigde hoeveelheid code wordt geschreven om de functie te implementeren.
Herstructurering
Stel dat u een grote codebasis hebt die u wilt herstructureren om bepaalde onderdelen sneller uit te voeren. Hoe weet u dat uw herstructureringsinspanningen er niet toe leiden dat delen van uw toepassing worden verbroken?
Geautomatiseerde tests fungeren als een soort contract. Dat wil gezegd, u geeft de invoer en de verwachte resultaten op. Wanneer u een reeks geslaagde tests hebt, kunt u uw code beter experimenteren en herstructureren. Wanneer u een wijziging aanbrengt, hoeft u alleen maar uw tests uit te voeren en te controleren of ze doorgaan. Nadat u uw herstructureringsdoelen hebt bereikt, kunt u uw wijziging indienen bij de build-pijplijn, zodat iedereen hiervan kan profiteren, maar met een lager risico dat er iets wordt onderbroken.
Welke typen geautomatiseerde tests zijn er?
Er zijn veel soorten geautomatiseerde tests. Elke test heeft een afzonderlijk doel. U kunt bijvoorbeeld beveiligingstests uitvoeren om te controleren of alleen geautoriseerde gebruikers toegang hebben tot een stukje software of een van de bijbehorende functies.
Wanneer we continue integratie en de build-pijplijn noemen, verwijzen we doorgaans naar ontwikkelingstests. Ontwikkelingstests verwijzen naar tests die u kunt uitvoeren voordat u de toepassing implementeert in een test- of productieomgeving.
Linttests, een vorm van statische-codeanalyse, controleert bijvoorbeeld uw broncode om te bepalen of deze voldoet aan de stijlhandleiding van uw team. Code die consistent is opgemaakt, is eenvoudiger voor iedereen om te lezen en te onderhouden.
In deze module werkt u met eenheidstests en codedekkingstests.
Met eenheidstests worden de meest fundamentele onderdelen van uw programma of bibliotheek gecontroleerd, zoals een afzonderlijke functie of methode. U geeft een of meer invoergegevens op samen met de verwachte resultaten. De testloper voert elke test uit en controleert of de werkelijke en verwachte resultaten overeenkomen.
Stel dat u een functie hebt waarmee een rekenkundige bewerking wordt uitgevoerd die deling omvat. U kunt een aantal waarden opgeven die uw gebruikers samen met edge-casewaarden, zoals 0 en -1, moeten invoeren. Als een bepaalde invoer een fout of uitzondering produceert, kunt u controleren of de functie dezelfde fout produceert.
Testen met codedekking berekent het percentage van uw code dat wordt gedekt door uw eenheidstests. Testen van codedekking kan voorwaardelijke vertakkingen in uw code bevatten om ervoor te zorgen dat een functie wordt gedekt.
Hoe groter uw codedekkingspercentage, hoe betrouwbaarder u kunt zijn dat u later geen fout ontdekt in code die niet volledig is getest. U hoeft de codedekking van 100 procent niet te bereiken. Wanneer u begint, zult u waarschijnlijk merken dat u een laag percentage hebt, maar dat geeft u een beginpunt waaruit u extra tests kunt toevoegen die betrekking hebben op problematische of veelgebruikte code.
Eenheidstests geïsoleerd houden
Wanneer u meer wilt weten over eenheidstests, hoort u mogelijk termen zoals mocks, stubs en afhankelijkheidsinjectie.
Zoals u weet, moet een eenheidstest een afzonderlijke functie of methode verifiëren en niet hoe meerdere onderdelen communiceren. Maar als u een functie hebt die een database of webserver aanroept, hoe gaat dat dan?
Er wordt niet alleen een aanroep naar een externe service-onderbrekingsisolatie uitgevoerd, maar dit kan de problemen vertragen. Als de database of webserver uitvalt of anders niet beschikbaar is, kan de aanroep de testuitvoering ook verstoren.
Met behulp van technieken zoals mocking en afhankelijkheidsinjectie kunt u onderdelen maken die deze externe functionaliteit nabootsen. Verderop in deze module krijgt u een voorbeeld.
Later kunt u integratietests uitvoeren om te controleren of uw toepassing correct werkt met een echte database of webserver.
Wat maakt een goede test?
U kunt een goede test beter identificeren wanneer u ervaring hebt met het schrijven van uw eigen tests en het lezen van tests die door anderen zijn geschreven. Hier volgen enkele richtlijnen voor het aan de slag gaan:
- Test niet in het belang van testen: uw tests moeten een doel dienen, behalve een controlelijstitem om af te kruisen. Schrijf tests om te controleren of uw kritieke code naar behoren werkt en de bestaande functionaliteit niet onderbreekt.
- Houd uw tests kort: Tests moeten zo snel mogelijk worden voltooid, met name tests die plaatsvinden tijdens de ontwikkelings- en buildfasen. Wanneer tests worden uitgevoerd terwijl elke wijziging door de pijplijn loopt, wilt u niet dat ze het knelpunt zijn.
- Zorg ervoor dat uw tests herhaalbaar zijn: testuitvoeringen moeten telkens dezelfde resultaten opleveren, ongeacht of u ze uitvoert op uw computer, de computer van een collega of in de build-pijplijn.
- Houd uw tests gefocust: Een veelvoorkomende misvatting is dat tests bedoeld zijn om code te behandelen die door anderen is geschreven. Normaal gesproken moeten uw tests alleen betrekking hebben op uw code. Als u bijvoorbeeld een opensource-grafische bibliotheek in uw project gebruikt, hoeft u die bibliotheek niet te testen.
- Kies de juiste granulariteit: als u bijvoorbeeld eenheidstests uitvoert, mag een afzonderlijke test niet meerdere functies of methoden combineren of testen. Test elke functie afzonderlijk en later schrijfintegratietests om te controleren of meerdere onderdelen goed werken.
Welke typen testhulpprogramma's zijn beschikbaar?
De testhulpprogramma's die u gebruikt, zijn afhankelijk van het type toepassing dat u bouwt en het type test dat u wilt uitvoeren. U kunt selenium bijvoorbeeld gebruiken om ui-tests uit te voeren op veel soorten webbrowsers en besturingssystemen.
Ongeacht de taal waarin uw toepassing is geschreven, zijn er veel testhulpprogramma's beschikbaar die u kunt gebruiken.
Voor Java-toepassingen kunt u bijvoorbeeld Checkstyle kiezen om linttests uit te voeren en JUnit om eenheidstests uit te voeren.
In deze module gebruiken we NUnit voor eenheidstests, omdat deze populair is in de .NET-community.