+31 (0) 53 30 33 600

Hoe realiseer je kwalitatief goede code

 – Automatiseer testen  (‘Automate tests’)

- Blog 6 - 

Kwalitatief goede software voorkomt hoge kosten voor onderhoud en aanpassingen, performance problemen, downtime, gegevensverlies en imagoschade. Vandaar dat we bij OVSoftware garant staan voor de goede kwaliteit van de softwarecode die we opleveren. Dit doen we onder andere door bij de ontwikkeling van maatwerk softwareoplossingen de tien richtlijnen voor codekwaliteit van de Software Improvement Group (SIG) toe te passen. In een serie van tien blogs leggen onze IT-specialisten uit wat deze richtlijnen zijn, hoe zij developers ondersteunen bij het schrijven van code en welke voordelen ze opleveren voor de klant.

‘Automate tests’ – wat houdt dat in?
Als je het hebt over geautomatiseerd testen dan gaat het over het testen van de code units waarbij je kijkt of zij doen wat ze moeten doen. Een unit is een functie in je softwarecode die een bepaald  aantal regels code uitvoert, bijvoorbeeld het versturen van een e-mail. Bij het testen van de unit kijk je naar heel veel verschillende aspecten. Denk aan de diverse ontwikkelpaden (beslisbomen voor  uiteenlopende scenario’s) of aan de werking van de unit met of zonder inzet van parameters*. Bij het testen kijk je niet alleen of de werking van de functie goed uitpakt, maar probeer je ook vooral dingen uit die fout kunnen gaan. Stel je hebt bepaald dat je een foutmelding wilt ontvangen op het moment dat er geen waardes in de parameter staan. Bij de test blijkt echter dat de unit gewoon doorgaat, zonder deze melding af te geven. Dan weet je dat er aanpassingen nodig zijn. Geautomatiseerde testen worden vaak als regressietest ingezet. Bij elke aanpassing of uitbreiding van de code wordt daarbij gecontroleerd of er niet onbedoeld iets is stukgegaan in de code. Blijkt uit de test dat dit het geval is, dan kun je dit direct controleren en waar nodig corrigeren.

*  Parameters van een functie zijn aanvullende stukjes informatie die worden gebruikt binnen de code unit. In genoemd voorbeeld van ‘het versturen van een e-mail’ zijn dit bijvoorbeeld de aanhef, onderwerpregel of mee te sturen bijlagen.

Martin Aarnoudse

Meer informatie? Neem contact met mij op!



De richtlijn toegepast in de praktijk
Ik heb wel eens aan de hand gehad dat ik een unit moest bouwen, maar nog niet handmatig kon testen omdat ik op dat moment nog niet via de applicatie bij de betreffende unit kon komen. Ik heb toen alle mogelijke unittesten schreven en uitgevoerd met een 100% ‘goed’ als resultaat. Ik kon de geschreven code met een gerust hart opleveren, want wat er ook gevraagd zou worden, de unit zou doen wat hij moest doen. Nu vraag je je wellicht af hoe je er zeker van kunt zijn dat je alles hebt getest wat er maar te testen valt. Dat doe je door gebruik te maken van een Test Framework dat in elke ontwikkelomgeving beschikbaar is. Zodra je je testen hebt uitgevoerd, kleurt het onderdeel van de unit dat hiermee geraakt is en positief bevonden op groen en zie je of je nog delen hebt gemist. De kwaliteit van de ontwikkelaar is natuurlijk bepalend voor de opzet van de tests die worden gedraaid en dus uiteindelijk voor de kwaliteit van de opgeleverde code.


Zo helpt de richtlijn mij als ontwikkelaar
Het automatiseren van testen helpt je als developer om te checken of aangepaste software nog steeds doet wat het moet doen. Het helpt je ook wanneer er nog geen andere mogelijkheid is om de unit te testen, zoals in eerder genoemd voorbeeld. Het geeft je houvast, de zekerheid dat het goed is. Dat geldt voor je eigen code en voor de code van anderen die je mogelijk minder goed kent. Je krijgt dan de bevestiging (of niet) dat je niets ongewild hebt aangepast of stukgemaakt. Het toepassen van deze richtlijn wil niet zeggen dat er nooit fouten in je code zullen zitten – wel stelt het je in staat om gemaakte fouten sneller te ontdekken en corrigeren. Vergeleken met manueel testen is automatisch testen veel eenvoudiger, sneller en preciezer.

Dit levert de richtlijn op voor de klant 
Projecten waarbij gebruik wordt gemaakt van automatisch testen, vallen qua kosten hoger uit omdat het opzetten en uitvoeren van testen initieel meer tijd kost. Helaas wordt er vaak om die reden besloten om dit onderdeel te laten vallen. De negatieve impact op de onderhoudbaarheid van de software op langere termijn, wanneer aanpassing van code nodig is, wordt daarbij vergeten. Is je code niet getest, dan weet je nooit of een aangepaste variant goed of fout gaat. Als je op dat moment handmatig gaat testen, kom je er al snel achter dat dat in de meeste gevallen bijna niet te doen is en juist hierbij ontstaan veel fouten. Dus mijn advies is altijd: ga voor automatisch testen want op termijn leidt dit altijd tot grotere efficiency, betere onderhoudbaarheid en eenvoudiger aan te passen softwarecode.


Over de auteur

Martin is Senior IT-Professional bij OVSoftware met een specialisatie in .NET en Blockchain. Hij heeft veel ervaring met het ontwikkelen van maatwerk software voor klanten, voornamelijk binnen de overheid. Daarnaast adviseert hij hen over het wel/niet inzetten van Blockchain en geeft hij presentaties over dit onderwerp aan divers publiek (bedrijven, overheid, developers, studenten). Begeleiden van afstudeerders bij het proces en inhoudelijk op het gebied van IoT en Blockchain hoort ook bij zijn taken.

Contact

Wil je meer informatie over OVSoftware?
Neem dan contact op.

Werken bij OVSoftware

Wil je meer weten over onze bedrijfscultuur en vacatures?
Bekijk dan onze werken bij pagina

Branches

Wil je meer weten over de branches waarbinnen OVSoftware actief is?
Bekijk de branches.

Referenties & Projecten

Lees hier klantreferenties en door OVSoftware begeleide lopende en afgeronde projecten waar wij trots op zijn.

Over ons

OVSoftware is één van de eerste softwarebedrijven van Nederland.
Lees meer over ons.

Volg ons op