JorisR.be

JorisR.be

Code-Run-Beer-Repeat
8-11-2017

Unit testing: to unit test or not to unit test?

Op de verschillende projecten waar ik aan gewerkt heb, was er telkens een andere opvatting over unit testing. Bij het ene project moest er minstens 70% code coverage zijn, bij het andere project werd er helemaal niets getest.

Maar meestal begint men volle moed om unit tests te schrijven en wordt dit na enkele dagen/weken/maanden stopgezet omdat er een deadline zit aan te komen en unit testing alleen maar tijd kost, en niets toevoegd aan het project.

Daarom deze post: Wat moet een unit test testen?

Waarom

Eerst het misverstand uit te de weg helpen dat unit testen alleen maar tijd kost, en niets toevoegd aan het project

  • Sneller fouten opsporen: het zou niet de eerste keer zijn dat iemand aanpassingen aan een stuk code doet en zo nieuwe bugs creëert.  Als er voor dit stuk code een goede unit test bestaat, zal dit sneller opvallen, en kan je bekijken of de unit test niet meer geldig is dan wel de aanpassing verkeerd was.
  • Je wordt geforceerd om na te denken over het stuk logica dat geprogrammeerd is: welke situaties kunnen allemaal voorvallen?  Als je hier over nadenkt, gaat je code er ook anders uitzien dan wanneer je er gewoon aan begint.
  • Je bent niet afhankelijk van externe services om te testen.  In veel applicaties maakt men gebruik van externe services om gegevens op te halen.  Als je aan het ontwikkelen bent en je wilt je aanpassingen testen, kan het zijn dat deze extreme service het laat afweten.  Maak je gebruik van unit testing, kan je deze service 'mocken', en kan je beter inspelen op je verwachte uitkomst.

 

Best practices

  • Waarvoor dien je een unit test te schrijven?  Het heeft geen zin om voor elke functie een unit test te schrijven.  Een unit test voor een functie die alleen een record wegschrijft naar een database heeft bijvoorbeeld weinig zin.  Het wegschrijven naar de database is een communicatie met een ander systeem, dus het enige dat fout zou kunnen gaan is niet de verantwoordelijkheid van deze functie.  Een integratie test kan hier wel van belang zijn!
    Ook unit testen te gaan schrijven voor aan een bepaald getal van code coverage te geraken is een slechte manier, code coverage zegt niet alles.  Code coverage kan wel aangeven dat er voor een bepaald deel van je code geen unit testen zijn.  Aan jouw dan om te bekijken of er effectief testen te weinig zijn.
  • Test 1 'unit' tegelijk: Maak het te testen deel per unit test zo klein mogelijk.
  • Bij het vaststellen van de architectuur van je code, houd dan altijd de testen in uw achterhoofd.  Gebruik dus bij voorkeur dependency injection, zodat je interfaces kunt mocken,  zo maak zo je code veel testbaarder.
  • Groen licht maakt geen goede unit test: Het is niet omdat je unit test slaagt, dat deze een goede unit test is.  Voor een goede test is het niet genoeg zomaar wat af te testen, zie dat je testen al de paden in de code afgaan: de meest voorkomende, maar ook de uitzonderingen.
  • Test ook op exceptions die kunnen voorvallen.  Wat gebeurt er bijvoorbeeld als een parameter null is?  Maar ook als je zelf een exception throwt, zorg dan dat je minstens 1 test hebt die deze exception laat gebeuren.
  • Elke test moet op zichzelf staan.  Er mag dus niet uitgegaan worden van een resultaat dat een andere test heft gedaan.
  • Mock elke externe service: Je kan nooit uitgaan van 100% werkende externe services, dus daarom kan je ze maar beter mocken.

 

Leave A Comment