[Alg] wie unit-test er allemaal?

[Alarmnummer]

Ik gebruik nu al een maar dan een jaar (ik denk intussen wel 2) unit tests bij mijn software en de laatste tijd maak ik er steeds intensiever gebruik van. Je bent in het begin even bezig om ze op te zetten (vooral in oudere systemen waar het niet van het begin af aan is gebruikt kost het veel werk zonder direct resultaat), maar als je het een beetje bij houd dan valt het gelukkig mee.

Het grootste voordeel dat JUnit mij geeft is vertrouwen in mijn software. Iedereen maakt fouten en volledige correctheidsbewijzen opstellen voor software is geen optie omdat de software dan onbetaalbaar gaat worden. Daarnaast heb je natuurlijk in veel kortere tijd een bug gespot dan de tradionele manier: zelf proberen. Verder heb ik de unit tests gekoppeld aan mijn buildscript : ANT, zodat ik automatisch alle tests kan uitvoeren (en na afloop zo`n fijne build succesfull op het scherm krijg die je niet krijgt te zijn bij een fout in je unit tests).

Ik zou dus graag willen wie er nog meer unit tests gebruikt in zijn software, en hoever je ermee gaat.

Voor het geval mensen niet weten wat het niet is:

Een unit test is testcode waarmee je kan controleren of je software ook doet wat het moet doen. Voor een java versie kan je kijken naar JUnit en voor een .NET version kan je kijken naar: NUnit

De java mensen kunnen eventueel ook nog even kijken naar
Clover, waarmee je kan zien welk gedeelte van de software door de unit tests is getest. Op zich is het een handige tool, maar ik heb er zo mijn twijfels over. Maar je moet een reeks testen schrijven voor een bepaald stuk functionaliteit, dus het komt erop neer dat je meerdere keren dezelfde methodes moet aanroepen. Clover kan niet controleren of jij wel de noodzakelijke combinaties hebt geprobeerd, en hij vind 1 combinatie al goed om te zien of de code ook ge-execute is.

[edit]
Binnen de XP stroming, is het Unit testen een must. Binnen zo`n stroming ontstaan weer allemaal nieuwe substromingen en een daarvan is Test Driven Development. Hierbij ga je eerst je tests schrijven, en daarna pas de code implementeren. Deze manier van aanpak heeft als voordeel dat je beter gaat nadenken over wat je code moet gaan doen, en dat natuurlijk je tests altijd geschreven worden. Gelukkig zeggen ze niet dat dit de enigste manier van werken is, maar in sommige gevallen kan het heel handig zijn. De techniek pas ik zo nu en dan ook toe. Voor mijn parsers bv schrijf ik eerst de 'rotte' file die geparst moet worden, en daarna verwerk ik het pas in de parser.

[ Voor 23% gewijzigd door Alarmnummer op 13-10-2003 11:40 ]

[Varienaja]

edit:
niet langer van toepassing

[ Voor 96% gewijzigd door Varienaja op 27-02-2006 13:00 ]

[Alarmnummer]

Varienaja schreef op 13 oktober 2003 @ 11:12:
Echt waanzin bij ons. Tuurlijk heb ik het management al meer dan eens op het belang van correctheid en tests gewezen. Dan kijken ze altijd heel bezorgd, en dan zeggen ze dat er inderdaad vanalles moet veranderen. Een uur later staan ze weer aan je bureau om te zeuren dat je dit en dat en dat nog even moet fixen, en dan een nieuwe release naar klant A moet sturen

Vanuit managment oogpunt is unit testen idd ook iets vreemds. Je steekt tijd in niet functionele code, en het is dan ook logisch om te concluderen dat je je tijd niet functioneel besteed. En tijd niet functioneel besteed is verloren geld.

Het voordeel aan een unit test is dat je die niet meer met de hand handelingen moet verrichten om je systeem in een bepaalde toestand te brengen om daarna die test uit te voeren. Dit kost ook tijd, en deze tijd kan je beter besteden aan een unit test, omdat deze test dus altijd geautomatiseerd geexecute kan worden.

Systemen waarbij vanaf het begin geen rekening is gehouden met unit tests kunnen een drama zijn om alsnog unit tests in uit te voeren. Je moet eerst een hele zwik objecten aan de praat slingeren voordat je tests kan uitvoeren. Met unit tests maak je ook testbare code en imho komt dit je ontwerp zeker ten goede.

[Glimi]

Bij mij hangt het er nogal van af. Ten eerste ben ik geen commerciëel ontwerper en/of devver dus is de 'nood niet zo hoog' zeg maar

Ten tweede is het ook wat er gebouwd is.
Bijvoorbeeld, pas heb ik een quicksort algoritme gebouwd. Natuurlijk wordt dat getest met een unit test, omdat het ook makkelijk te definieëren is wat zo'n test moet inhouden.
Maar wat te doen bij concurrent software? Wat te doen bij GUI's? Kortom, wat te doen bij dingen die niet zo makkelijk wiskundig te beschrijven zijn?

[Alarmnummer]

Glimi schreef op 13 October 2003 @ 11:28:
Bij mij hangt het er nogal van af. Ten eerste ben ik geen commerciëel ontwerper en/of devver dus is de 'nood niet zo hoog' zeg maar

Voor al mijn open source projecten (die dus binnenkort op mijn nieuwe site komen te staan) gebruik ik overal unit tests voor. Het geeft een veiliger gevoel en ik maak nog zo vaak een stomme fout.

Ten tweede is het ook wat er gebouwd is.
Bijvoorbeeld, pas heb ik een quicksort algoritme gebouwd. Natuurlijk wordt dat getest met een unit test, omdat het ook makkelijk te definieëren is wat zo'n test moet inhouden.
Maar wat te doen bij concurrent software? Wat te doen bij GUI's? Kortom, wat te doen bij dingen die niet zo makkelijk wiskundig te beschrijven zijn?

Dingen die makkelijk wiskundig beschrijfbaar zijn, kan je denk ik ook eenvoudig een correctheids bewijs van leveren. Bij normale grotere stukken gaat deze vlieger al niet eens meer op. Trouwens.. er zijn ook addons te krijgen voor bv junit waarmee je gui`s kan testen en multi-threading.

[mbravenboer]

Unit testen? Tuurlijk! .

Al m'n pakketten staan onder controle van unit tests. Het aardige is dat al deze pakketten (en vele andere) dagelijks gebouwd worden in een buildfarm, waarin tijdens het build proces ook de unit tests toegepast worden.

Het heeft me erg veel geholpen tijdens de ontwikkeling van m'n software, maar ik moet ook wel zeggen dat het type software zich uitstekend leent voor unit testing. Er zijn veel vertalingen van taal A en taal B, die uitstekend getest kan worden op kleine fragmenten van taal A. Veel projecten zullen veel minder geschikt zijn voor testing mbv unit testing.

Even een beetje reklame voor een projectje wat hier op de UU bezig is .

[bigtree]

Varienaja schreef op 13 October 2003 @ 11:12:
Ik werk bij een uit z'n kluiten gegroeid cowboy-bedrijf. Wij testen eigenlijk niks. De ontwikkelaars (waaronder ikzelf) krijgen de opdracht om bepaalde nieuwe dingen te maken. Dit maak ik dan, en klooi ermee totdat 't werkt.

Gemiste kans natuurlijk. Het management is vast wel vatbaar voor het argument dat je tests kunt begroten op de offerte (= meer omzet). Of je ze vervolgens uitvoert is een tweede, maar vaak worden ze simpelweg 'vergeten' op de offerte. Dom dom dom.

[Alarmnummer]

bigtree schreef op 13 oktober 2003 @ 11:59:
[...]
Gemiste kans natuurlijk. Het management is vast wel vatbaar voor het argument dat je tests kunt begroten op de offerte (= meer omzet). Of je ze vervolgens uitvoert is een tweede, maar vaak worden ze simpelweg 'vergeten' op de offerte. Dom dom dom.

Je moet er natuurlijk wel rekening mee houden dat er meerdere concurrende bedrijven zijn en dan wil je natuurlijk wel zo goedkoop mogelijk zijn.

Verder hoeft het niet te betekenen dat projecten met unit testen duurder zijn dan die zonder. Als je code schrijft ga je het testen. Je kan dit op de 'tradionele' manier doen door met de hand op knoppen te gaan drukken en kijken of iets ook daadwerkelijk veranderd is bv. Maar je zou ook een stuk code kunnen gaan schrijven die dit voor je gaat testen. In beide gevallen ga je dus testen, maar alleen in het laatste geval kan je die testen ook later weer uitvoeren.

Het idee achter XP is dat je zo snel en goedkoopmogelijk stabiele software op de markt gaat brengen en unit testen is hierbij een must. Hieruit zou je kunnen concluderen dat unit testen de software niet duurder maken.

Verder zie ik dit zelf ook. In het begin ben je tijd kwijt om unit tests op te zetten, maar deze tests kan je dus altijd weer uitvoeren. Hierdoor ben ik veel minder tijd kwijt met debuggen.

Trouwens.. ik heb intussen al in een aantal boeken zien staan dat je een bug ook mbv een unit test kan proberen op te sporen. En een bijkomend voordeel is dat je de kwaliteit van je systeem ook verhoogt.

[bigtree]

Alarmnummer schreef op 13 October 2003 @ 12:08:
[...]

Je moet er natuurlijk wel rekening mee houden dat er meerdere concurrende bedrijven zijn en dan wil je natuurlijk wel zo goedkoop mogelijk zijn.

Eens. Maar het aanbieden van een scherpe prijs mag natuurlijk niet ten koste gaan van kwaliteit. Als ik een offerte voor maatsoftware krijg waar geen bedrag voor testen is begroot, trek ik de kwaliteit van die aanbieder in twijfel. Een opdrachtgever zal nooit willen bezuinigen op het testen van zijn product. (Weet ik uit ervaring, 10% voor testen is altijd ok )

Verder hoeft het niet te betekenen dat projecten met unit testen duurder zijn dan die zonder. Als je code schrijft ga je het testen.

Inderdaad, dus mag je het ook zeker opnemen in je begroting. Die kosten maak je immers. Dat je op lange termijn kunt bezuinigen op testen door gebruik te maken van test units, prima! Op die manier gaan lagere (kost)prijs en hogere kwaliteit zelfs hand in hand.

[Ralluph]

Varienaja schreef op 13 October 2003 @ 11:12:
Ik werk bij een uit z'n kluiten gegroeid cowboy-bedrijf. Wij testen eigenlijk niks. De ontwikkelaars (waaronder ikzelf) krijgen de opdracht om bepaalde nieuwe dingen te maken. Dit maak ik dan, en klooi ermee totdat 't werkt.

Dit komt mij bekend voor, ik werk ook bij zo een bedrijf. Een paar jaar geleden zijn wij enorm gegroeid, en tijdens die groei lag de focus van de bedrijfsvoering vooral op het binnenhalen van nieuwe orders en minder op de kwaliteit van de opleveringen. Zeker in het verleden hebben wij nogal eens gezeik gehad met niet werkende bestaande functionaliteit, omdat we simpelweg dachten "in de vorige release werkte het wel".
Geautomatiseerd unit-testen doen wij helaas nog niet. De reden hiervan is inderdaad dat de projectteams nog steeds zo krap bemeten zijn dat hier weinig tijd voor is. Natuurlijk verdient het aanleren van deze gewoonte zich ongetwijfeld terug, maar het proces van aanleren kost aanlooptijd en die is er niet.

bigtree schreef op 13 oktober 2003 @ 11:59:
Gemiste kans natuurlijk. Het management is vast wel vatbaar voor het argument dat je tests kunt begroten op de offerte (= meer omzet). Of je ze vervolgens uitvoert is een tweede, maar vaak worden ze simpelweg 'vergeten' op de offerte. Dom dom dom.

Ik vrees zelfs dat ons management dit wel aan de klant geoffreerd heeft, maar dat we dit niet doen... Een andere strategie die wij succesvol hebben toegepast is de verantwoordelijkheid voor het testen contractueel volledig bij de klant neer te leggen. De persoon die dit destijds heeft verkocht komt wat mij betreft in aanmerking voor de Nobelprijs voor martketing .
Wel hebben we een aardig systeem waarbij ontwikkelaars componenten van hun collega's moeten testen. Dit voor elke oplevering. Natuurlijk werkt dit niet zo goed als geautomatiseerd unit-testen, maar het heeft ons al vele nare verrassingen bespaard.

Waar wij overigens wel erg mee bezig zijn is geautomatiseerd functioneel regressie-testen. Hierbij test je of de applicatie als geheel nog steeds aan de functionele requirements voldoet. Deze tests worden meestal door de GUI uitgevoerd. Hiervoor zijn allerhande peperdure enterprise tools op de markt, zoals Mercury Interactive's WinRunner, Rational's XDE Tester en Rational Robot. Mijn ervaring is echter dat de ontwikkeling van deze tests vaak overdreven veel aandacht vereist. Dit komt vooral omdat kleine wijzigingen in de GUI de hele automatische teststraat overhoop kunnen halen. Misschien moet ik het management maar eens gaan porren om die ontwikkeling wat te remmen en de vrijgekomen tijd aan unit-testen te besten.
Ik vraag mij - bij wijze van side-topic- overigens af of er nog meer mensen hier op GoT zijn die ook aan geautomatiseerd functioneel regressie-testen doen.

[Varienaja]

edit:
niet langer van toepasing

[ Voor 92% gewijzigd door Varienaja op 27-02-2006 13:01 ]

[Verwijderd]

nu we het toch over testen hebben! Ik ben goede test tools aan het zoeken voor een C/C++ omgeving. visual c++/ codewarior 8.3

heb natuurlijk al een beetje geexperimenteerd met Cunit... maar als iemand ervaring heeft met andere/ betere test tools... laat het even weten!

[Johannes]

Varienaja, mag ik je misschien http://c2.com/cgi/wiki?ChangeYourOrganization en de gerelateerde pagina's (ChangeYourOrganizationDiary, ChangeYourOrganizationTactics) aanraden als je het gevoel hebt dat je hier zelf iets aan wil veranderen. Ook CategoryAdoptingXp is hier relevant.

[Amras]

Bij ons op de TU hebben we een college over Softwarekwaliteit & Testen. Hier wordt ons enorm aangeraden om dit toch te doen (en ook tig andere testsoorten). Ben zelf nog niet echt bezig geweest met een prog waar ik het nodig vond om flink te testen, maar hoop mezelf toch aan te kunnen leren dit wel altijd te gaan doen (scheelt een hoop stomme fouten).

[Verwijderd]

Verwijderd schreef op 13 October 2003 @ 13:21:
nu we het toch over testen hebben! Ik ben goede test tools aan het zoeken voor een C/C++ omgeving. visual c++/ codewarior 8.3

heb natuurlijk al een beetje geexperimenteerd met Cunit... maar als iemand ervaring heeft met andere/ betere test tools... laat het even weten!

Zelf ben ik redelijk over TCL te spreken. Het is bij deze scripttaal (net als veel anderen, dat moet ik wel toegeven) vrij gemakkelijk om bepaalde interfaces van de software naar de TCL scripts te exporteren. Als je dan vervolgens in TCL een aantal testcases definieert en een rapportage laat genereren dan is het goed te doen om bijvoorbeeld een sharedlibrary of serverapplicatie automatisch 's nachts te laten testen. Het voordeel hiervan is dat de testcases bestaan uit redelijk eenvoudige scripts i.p.v C of C++ code.

In het algemeen qua automatisch testen is mijn ervaring dat het moeilijke is om de eerste opzet van de testomgeving te maken. De tijd die hieraan wordt besteed lijkt in eerste instantie niets op te leveren. Pas op het moment dat de tests herhaald moeten worden (welk product of omvangrijke wijziging heeft maar 1 testrun nodig ? ) begin je met grote sprongen tijd- en budget winst te halen.

[Delphi32]

Unit tests zijn vrij recent bij ons ingevoerd. Voor bestaande code hebben we een dekkingspercentage dat rond de 0.1% ligt, maar voor alle nieuwe code willen we een zo hoog mogelijke dekkingsgraad. Dit, en tezamen met het pair programming, moet ervoor gaan zorgen dat onze software een veel hogere kwaliteit heeft voordat het zelfs maar het QA-department haalt.
Tot nu toe blijkt aan alle kanten dat het systeem van Unit Tests en Pair Programming uitermate efficiënt werkt. Unit Tests (we gebruiken DUnit, voor Delphi dus) geven een verhoogd vertrouwen in de gemaakte software en verminderen de 'er is iets omgevallen, help!'-paniekreacties, Pair Programming zorgt ervoor dat je veel minder stomme fouten maakt. Die worden er immers al grotendeels uitgevist door je maatje
"If code reviews are good, we will review code all the time."

[farlane]

Zou er eigenlijk eerst eens dieper in moeten duiken, maar ik ben benieuwd hoe zo'n unit test eigenlijk in elkaar zit....

Is het zo dat je geautomatiseerd objecten laat aanmaken en daarop methodes aanroept ? En hoe test je dan de interactie met andere objecten ?
Wanneer is een test geslaagd ? Moet je eerst de input en de verwachte output vaststellen of hoe gaat dat ?

[whoami]

farlane schreef op 14 October 2003 @ 09:16:
Is het zo dat je geautomatiseerd objecten laat aanmaken en daarop methodes aanroept ?

Een unit test kan je zien als een 'script' die het te testen object/class gaat gaan testen, door de methodes ervan aan te roepen voor allerhande waarden.

En hoe test je dan de interactie met andere objecten ?

Dat valt buiten de scope van een unit test. Een unit test is bedoeld om een class/algoritme op zich te testen.
Nagaan dus of het algoritme/class op zich de gewenste resultaten aflevert, onafhankelijk v/d buitenwereld.
Testen van de interactie van dat object met de buitenwereld doe je dmv een 'integration test'.

[igmar]

Alarmnummer schreef op 13 October 2003 @ 11:03:
Het grootste voordeel dat JUnit mij geeft is vertrouwen in mijn software. Iedereen maakt fouten en volledige correctheidsbewijzen opstellen voor software is geen optie omdat de software dan onbetaalbaar gaat worden. Daarnaast heb je natuurlijk in veel kortere tijd een bug gespot dan de tradionele manier: zelf proberen. Verder heb ik de unit tests gekoppeld aan mijn buildscript : ANT, zodat ik automatisch alle tests kan uitvoeren (en na afloop zo`n fijne build succesfull op het scherm krijg die je niet krijgt te zijn bij een fout in je unit tests).

Zoiets mis ik nog voor C. Valgrind maakt veel goed, maar niet alles. Testen en code-hergebruik zorgen vooral voor code die minder hard bugt, en de hergebruik scheelt schrijfwerk en testwerk.

Een unit test is testcode waarmee je kan controleren of je software ook doet wat het moet doen. Voor een java versie kan je kijken naar JUnit en voor een .NET version kan je kijken naar: NUnit

De java mensen kunnen eventueel ook nog even kijken naar
Clover, waarmee je kan zien welk gedeelte van de software door de unit tests is getest. Op zich is het een handige tool, maar ik heb er zo mijn twijfels over. Maar je moet een reeks testen schrijven voor een bepaald stuk functionaliteit, dus het komt erop neer dat je meerdere keren dezelfde methodes moet aanroepen. Clover kan niet controleren of jij wel de noodzakelijke combinaties hebt geprobeerd, en hij vind 1 combinatie al goed om te zien of de code ook ge-execute is.

Ik test bijna elke module apart, vooral de invoer van gegevens. Daarnaast dient alle software hier te compilen met -Wall -Werror, en valgrind-proof te zijn, dat wil zeggen : geen memleaks, geen errors.

Verder was testen een vak op de HTS, en die technieken gebruik ik nog steeds met enig regelmaat. Zeker een van de nuttige vakken, al is de materie erg droog van stof.

Binnen de XP stroming, is het Unit testen een must. Binnen zo`n stroming ontstaan weer allemaal nieuwe substromingen en een daarvan is Test Driven Development. Hierbij ga je eerst je tests schrijven, en daarna pas de code implementeren. Deze manier van aanpak heeft als voordeel dat je beter gaat nadenken over wat je code moet gaan doen, en dat natuurlijk je tests altijd geschreven worden. Gelukkig zeggen ze niet dat dit de enigste manier van werken is, maar in sommige gevallen kan het heel handig zijn. De techniek pas ik zo nu en dan ook toe. Voor mijn parsers bv schrijf ik eerst de 'rotte' file die geparst moet worden, en daarna verwerk ik het pas in de parser.

Parser schrijf ik in BNF, aan de hand van een eventuele testinput. Daarna gaat ie lex / yacc / lemon in, of schrijf ik 'm met de hand, afhankelijk van het uiteindelijke doel. Zeker als je d'r wat geschreven hebt klop je de lex / yacc uit je hoofd in, en vaak werkt ie ook nog eens in een keer.

Ik ben nu zelf met Lemon bezig, die is wat netter kwa syntax en resuktaat. Lex / yacc hebben ook wel wat nadelen, vooral als het om recursie gaat. En het is niet thread-safe, da's ook een groot nadeel.

Applicaties gaan vaak hier op papier, worden onderverdeeld in logische modules, en daarna pas gecode. Ook daar krijg je handigheid in, vooral het opzetten van goede datastructuren is een must. Zaken die eerst handig lijken (globale variabelen bv) zijn een grote no-no hier, op wat uitzonderingen na.

[igmar]

edit:

<snip> Eerst kijken, dan posten

[ Voor 96% gewijzigd door igmar op 14-10-2003 09:48 ]

[Alarmnummer]

igmar schreef op 14 October 2003 @ 09:29:
Parser schrijf ik in BNF, aan de hand van een eventuele testinput. Daarna gaat ie lex / yacc / lemon in, of schrijf ik 'm met de hand, afhankelijk van het uiteindelijke doel. Zeker als je d'r wat geschreven hebt klop je de lex / yacc uit je hoofd in, en vaak werkt ie ook nog eens in een keer.

Ik gebruik ook een parser generators, en syntactische controle laat ik ook fijn over aan de gegenereerde parser. De semantische controle daarintegen (bv een int a=true) controleer ik wel met behulp van unittest omdat dit (helaas ) niet gegenereerd wordt.

Ik heb meestal de volgende directories:
semantic-valid, semantic-invalid en deze worden door de unit test recursief afgelopen en hij verwacht dat het altijd goed of altijd fout is. Unit tests zijn nu super eenvoudig toe te voegen (hoef zelfs niet eens scripts of code aan te passen).

Ook voor het inlezen (en wegschrijven) van XML icm java gebruik ik ook unit tests, terwijl ik een Schema bestand gebruik voor syntactische validatie.

[ Voor 29% gewijzigd door Alarmnummer op 14-10-2003 11:24 ]

[Alarmnummer]

farlane schreef op 14 oktober 2003 @ 09:16:
Zou er eigenlijk eerst eens dieper in moeten duiken, maar ik ben benieuwd hoe zo'n unit test eigenlijk in elkaar zit....

Een unit test van een plus operator:

code:

public class PlusOperatorTest extends TestCase{
     public void runTest(){
          int a = 2;
          int b = 3;
          int c=a+b;
           assertTrue(5,c);
     }
}

Zoals je ziet is het dus erg eenvoudig

Is het zo dat je geautomatiseerd objecten laat aanmaken en daarop methodes aanroept ? En hoe test je dan de interactie met andere objecten ?

Je begint op laag nivo met testen (bv de plus operator test) en je werkt omhoog naar een hoger nivo. De interactie met andere objecten is meestal iets gecompliceerder en daar kan je in je ontwerp vaak ook beter rekening mee houden. Ik zorg ervoor dat het mogelijk is dat ik het gebied waarop ik test, eenvoudig kan indammen door bv proxies/stubs te gebruiken ipv werkelijke implementaties. In deze proxies controleer ik wat er terug wordt gestuurd en of er bv een foutmelding wordt opgeworpen.

code:

interface Client{
     public void kletsen()throws ClientException;
}

class CrashendeClient implements Client{
     public void kletsen()throws ClientException{
        throw new ClientException();
     }
}

Hiermee weet je dus dat je altijd een foutmelding krijgt en daarop zou je een test kunnen baseren (bv dat je systeem in een bepaalde toestand achterblijft door de exception).

Uiteindelijk ga je dus steeds hogerop testen, bouwend op de stabiliteit van de lagere tests.

Wanneer is een test geslaagd ? Moet je eerst de input en de verwachte output vaststellen of hoe gaat dat ?

Je maakt je objecten, laat ze met elkaar communiceren en dan ga je bv de output idd vergelijken. In mijn bovenstaande voorbeeld met die add ga ik dus testen of er ook 5 (het verwachte antwoord) is uitgekomen. Is dat niet zo, dan test is niet gelukt.

In dit geval is de test geslaagd als je een exception bent tegengekomen.

code:

class DivisionByZeroTest extends TestCase{

      public void runTest(){
          try{
               a=1/0;
                fail("devisonByZeroException expected");
          }catch(DevisionByZeroException ex){
          }
      }
}

Unit testen is dus niet ingewikkeld, en dat hoort het ook niet te zijn. Alle dingen die lastig en ingewikkkeld zijn worden niet op grote schaal toegepast door programmeurs, daarom is unit testen ook vrij eenvoudig.

[ Voor 4% gewijzigd door Alarmnummer op 14-10-2003 11:54 ]