Hoe ver gaan met unit testing?

[Waster]

Ik probeer mijn testskills te verbeteren. In mijn studie merk ik dat ik heel veel punten laat liggen door niet goed te testen aan het eind van de opdracht. Tegenwoordig doe ik wel meer aan integratie testen (zonder code nog ), maar unit testen komt er nog niet echt in. Ik heb me al wel ingelezen en met unit tests gespeeld. Maar wat het staat me nog een beetje tegen. Er moet namelijk het volgende gebeuren:

1. Interfaces specificeren zodat je mocks/stubs kan injecteren en de class in isolatie kan testen.
2. Methodes of constructors toevoegen om je mocks/stubs te injecteren.
3. Het schrijven van mocks/stubs (valt nog op te lossen met test frameworks)
4. Verschillende testen voor iedere specificatie van een methode.

Dat een ingewikkelde methode veel tests nodig heeft kan ik nog accepteren. Maar wat ik lastig vind is de impact die het heeft op het design. Interfaces en methodes die dwars door de normale connecties gaan tussen de classes. Het totaal aantal classes/interfaces lijkt te verdubbelen. En alle testcode en stubs/mocks is natuurlijk ook code, waar bugs in kunnen zitten. Simpele classes lijken heel gecompliceerd te worden als je ze designt voor testen. Dat gaat me een beetje te ver.

Wordt in de praktijk ook echt zo ver gegaan en iedere class in isolatie ge-unit test? Of wordt er een balans gezocht tussen helemaal niets testen en iedere class in isolatie testen? De basis classes zijn bijvoorbeeld heel simpel zonder stubs/mocks te testen omdat ze nergens vanaf hangen. En vervolgens kun je op een hiërarchische manier naar boven toe werken en eigenlijk steeds grotere integratie testen doen. Waarbij de correctheid van de testen van high-level objecten afhangen van de correctheid van de low-level objecten. Dit zou ik zelf nog wel een acceptabele vorm van testen vinden, omdat het geen impact heeft op je design. Maar echt unit-testen is het niet. De meeste designs die ik maak heeft namelijk niet of nauwelijks circulaire dependencies en er zijn altijd wel main classes en basis classes aan te wijzen. Als je dan van onder naar boven toe werkt moet je toch ook alles hebben getest?

[Avalaxy]

Ik kan moeilijk zeggen dat ik testbare code moeilijker vind dan slecht testbare code. Dit houdt voor mij concreet in dat ik voor een aantal classes (zoals repositories) een interface aanmaak waar ik de methodes in definieer, en door mijn dependency injection de interfaces aan de concrete implementaties laat koppelen. Vervolgens kun je heel makkelijk een object opvragen en mocken met een mocking framework.

Ik snap net precies wat in jouw ogen je classes zoveel complexer maken, heb je daar een voorbeeldje van? Ik zou namelijk haast durven zeggen dat als je gewoon goede object georiënteerde code schrijft, je nauwelijks extra moeite hoeft te doen om het goed testbaar te maken.

[ Voor 3% gewijzigd door Avalaxy op 22-11-2011 17:34 ]

[Waster]

Misschien speelt er ook nog wel iets anders mee. Ik schrijf zelf heel erg nette code al zeg ik het zelf. Besteed altijd redelijk veel aandacht aan het design en de leesbaarheid van de code. Resultaat is dat ik precies weet wat de code doet waar dan ook. Dat is in ieder geval één van mijn doelen als ik code schrijf. Ik denk dat het met unit testen ik een beetje het overzicht kwijt raak. Ik spendeer tijd aan het schrijven van testen voor classes waarvan ik weet dat ze moeten werken. Een extra test methode gaat dan nog net. Maar een mock objecten en interfaces vind ik denk ik over de top.

[RobIII]

Waster schreef op dinsdag 22 november 2011 @ 18:21:
Ik spendeer tijd aan het schrijven van testen voor classes waarvan ik weet dat ze moeten werken.

Het is natuurlijk afhankelijk van hoe je werkt maar doorgaans schrijf je éérst de test(s) en dan pas de implementatie. Maar los daarvan; de tests zullen vast allemaal succeeden wanneer je code 'vers' is, maar het hele idee is nou net dat wanneer je over 6 maanden terug komt en wijzigingen/fixes/whatever in je code aanbrengt dat je de tests opnieuw draait om te verifiëren dat alles nog werkt naar behoren. Wanneer er dan eventueel tests failen dan hebben die failed tests of te maken met de aanpassingen (en dus kan 't kloppen dat je tests nu failen en aangepast moeten worden naar de nieuwe situatie) of je hebt ergens een nieuwe bug geïntroduceerd omdat je na die 6 maanden 't overzicht niet meer helemaal had en niet besefte dat, bijv., aanpassing X ook effect had op onderdeel Y.
Daarbij zijn unit-tests IMHO bij uitstek geschikt om allerlei edge-cases te testen die je in productie waarschijnlijk niet (of nooit) zult tegenkomen. Je kunt voor allerlei edges en/of extremen testen en controleren of in die omstandigheden de werking ook nog correct is.

Waster schreef op dinsdag 22 november 2011 @ 18:21:
Maar een mock objecten en interfaces vind ik denk ik over de top.

Mock objecten ontkom je in sommige situaties niet aan maar zijn zeker niet altijd nodig. En als interfaces "over the top" zijn is je code misschien niet zo "heel erg net" als je denkt

Al-met-al hangt 't natuurlijk ook van de situatie af; ik ga voor een programma'tje van een paar regels code ook niet eerst een UML diagram maken, blauwdrukken schrijven, tests schrijven en dan pas implementaties bouwen. Sommige zaken zijn 't unittesten niet eens waard en andere zaken test je van elke mogelijke invalshoek. Zoals altijd (of meestal) in development: niet alles is zwart/wit. Zolang je weet waar je mee bezig bent (of; als je in teamverband werkt: zolang er duidelijke afspraken zijn over wat wel en wat niet) moet je gewoon doen wat je goed dunkt voor de betreffende situatie. Kun je je een 'misser' veroorloven in project/class/method X of kost 't je tonnen als er een foutje in zit? _{En hell, zelfs als 't tonnen kost kan 't soms niet de moeite waard zijn om er dagen aan unittests schrijven aan te besteden, maar dat komt niet héél veel voor Kosten/baten, perspectief enzo}

[ Voor 47% gewijzigd door RobIII op 22-11-2011 18:50 ]

[Varienaja]

Mijn motto is: van elke regel code die je schrijft wil je zeker weten dat 't doet wat je wilt. Om dat vast te stellen voer je je programma uit. Omdat het nogal suf is om 100.000x je programma te starten, in het menu te klikken, etc, etc, om uit te komen bij de code die je wilt testen vind ik Unittests het einde. Daarmee kan je zowat direct de te testen code aanroepen.
Tevens heb je daarmee zekergesteld dat je tests reproduceerbaar zijn en als klap op de vuurpijl heb je 'documentatie' (of toch in elk geval voorbeeldcode) van hoe je API te gebruiken.

Ik moet eigenlijk zeggen, dat door het testbaar maken van mijn klassen ze er eerder mooier van zijn geworden dan lelijker. Door direct tijdens het opzetten van je code de testbaarheid in het achterhoofd te houden heb ik het gevoel dat de code beter wordt gestructureerd.

Ik probeer doorgaans 100% afdekking te bereiken. Maar dat lukt me niet altijd met exception-handling code en dergelijke. Ook ingewikkelde booleaanse constructies in if-constructies krijg ik niet altijd 100% getest. Maar voor minder dan zo'n 80 à 85 % afdekking zou ik niet gaan. Anders heb je nog steeds zoveel ongeteste code in je programma dat je alsnog niks kan zeggen over de correctheid.

[ Voor 19% gewijzigd door Varienaja op 22-11-2011 21:51 ]

[Grompie]

Unit tests zijn vooral handig zoals Roblll al aangaf als je na x aantal maanden iets moet wijzigen in je code. En dit gebeurd bijna altijd. Een van de belangrijkste dingen die ik mijn achterhoofd houd tijdens het programmeren is dat alles later nog kan veranderen. Als je dan later in je programma iets veranderd en één van je unit test werkt niet meer weet je zeker dat er een bug in je programma zal zitten.
Verder vind ik het ook erg handig als je aan refactoring doet of gewoon om je code te testen. zonder die aan een GUI of console binden;
Ik zeg niet dat je voor ieder project unit tests moet schrijven, sommige projecten zijn eenmaal te klein om dit te doen.

Je sluit met unit tests niet alle problemen uit maar indien je tests goed zijn kom je met 90% al een heel eind.

[YopY]

Je geeft aan dat je het lastig vindt om je applicatie zodanig te schrijven dat je mocks / stubs kunt injecteren (inclusief interfaces e.d.). Het injecteren heeft een goeie reden: lees bijvoorbeeld eens dit klassieke stukje van Martin Fowler die dat even haarfijn uitlegt.

Persoonlijk ben ik van mening dat ik pas OOP kon programmeren toen ik unit tests probeerde te schrijven.

En wat betreft stubs / mocks en interfaces: Gebruik Mockito ipv het veel zwaardere en beperktere JMock. De laatste kan alleen maar interfaces mocken (Mockito ook concrete classes) en heeft een veel zwaardere syntax.


Met betrekking tot wat je moet testen: Alles. Als je niet vind dat je het moet testen moet je je toch even afvragen of je het wel zou moeten schrijven. (oké, zo alles-of-niets is het ook niet, maar denk er toch over na: als ik er geen test voor kan of wil schrijven, is het dan wel waard om te schrijven? Ten tweede: Als het moeilijk is om een test te schrijven, heb ik dan wel het goeie ontwerp? Moeilijk testbare code is een code smell; goed testbare code is in 99.9% ook goeie / mooie code)

En als je moe wordt van het schrijven van tests, pak eens een andere taal of framework. Een taal als Scala leent zich voor een meer DSL-achtige aanpak voor unit tests (bijv. door Specs2), en je kunt het gewoon in een Java project integreren.

Puur uit nieuwsgierigheid: Wat voor code probeer je te testen? Zet eens een voorbeeld op pastebin of gist oid, zowel voor als na je er een test voor geschreven hebt? Je wordt afgekraakt als het lelijke / moeilijk testbare code is overigens .

[ Voor 7% gewijzigd door YopY op 23-11-2011 21:44 ]

[RobIII]

YopY schreef op woensdag 23 november 2011 @ 21:43:
En wat betreft stubs / mocks en interfaces: Gebruik Mockito ipv het veel zwaardere en beperktere JMock. De laatste kan alleen maar interfaces mocken (Mockito ook concrete classes) en heeft een veel zwaardere syntax.

Wie heeft 't hier over Java? Wie weet gaat 't wel over .Net? En maakt 't überhaupt uit voor de discussie (in SEA)?

[chime]

Test Driven Design => eerst je test schrijven, dan pas je implementatie.

Op die manier is je code altijd afgetest + je schrijf ad hoc niet even snel wat extra code erbij (want dat kan wel es handig zijn voor later ... not)

Ook leer het je eerder denken over hoe een klasse te benaderen.
Als je even 200 regels setup moet schrijven voordat je 1 kleine functie kan testen ... dan weet je dat die functie teveel info nodig heeft.

Als de code goed is afgetest kan je die achteraf veel makkelijker wijzigen en refactoren.
Je "weet" als het ware dat je toch niks kunt kapot krijgen .. zonder dat je testen alarm slaan.

Persoonlijk gebruik ik nagenoeg geen stubs, gewoon standaard mock klasses zijn vaak al voldoende.
Je wilt dat je test blijft functioneren ook al pas je andere klassen aan die de klasse die je test gebruikt.
(Integratie test is weer anders, daar gebruik je de echte klasses en geen enkele mock ... maar daar doe je er maar een paar van)

Testen schrijven nadat de code is geschreven is eigenlijk niet goed:
1) je schrijft je test naar de code, kans dat je fouten gaat ontdekken is klein (dit in tegenstelling tot een test die je baseert op de analyse / test plan van je analyst
2) je gaat dingen testen die misschien niet ontwikkeld hadden moeten worden
3) het komt vaak als overbodig werk over (want de code bestaat al en werkt, dus waarom testen) => demotiverend

[Grijze Vos]

chime schreef op donderdag 24 november 2011 @ 12:24:
3) het komt vaak als overbodig werk over (want de code bestaat al en werkt, dus waarom testen) => demotiverend

Ik denk dat dat het belangrijkste is. Als je code al af is kan de test onder tijdsdruk weggelaten worden, als je begint met je tests kan dat iig nooit.

[SiErRa]

Unittesten gaat wel een stuk makkelijker als je het mocken een beetje onder de knie hebt.
Ook wat trucjes kennen zoals het onder .Net exposen van internals naar je unittest project is erg handig.

Het gevoel dat het een beetje jammer is dat je je code soms wat naar je tests moet schrijven had ik in het begin ook, maar elke jaren en wat behoorlijke refactorslagen in goed geteste code later neem ik dat wel op de koop toe.

Qua kosten van tijd valt het best mee, initieel denk je in ieder geval een stuk beter na over je code als je je test eerst schrijft en zal je waarschijnlijk minder defect terug krijgen, maar de echte winst komt met onderhoud pas.

Wij hanteren standaard een code coverage van minimaal 80%, als je hier onder zit moet je wel een goede reden hebben (is ook zichtbaar in het nightly build overzicht), dat kan bijvoorbeeld als er veel gegenereerde code (proxies) is en ook frontends (asp.net webforms) hebben nog wel eens mindere coverage, al wordt de logica wel netjes gescheiden en goed getest.

Veel mensen proberen complete integratie tests te schrijven dmv. unittests, en klagen dan dat het moeilijk is. Maar dan heb je niet goed begrepen dat je je "unit" klein moet houden

[Woy]

SiErRa schreef op dinsdag 29 november 2011 @ 22:18:
Ook wat trucjes kennen zoals het onder .Net exposen van internals naar je unittest project is erg handig.

Dat is iets wat je juist niet nodig hebt als je je code goed opgezet hebt, en de juiste mocks/stubs gebruikt. De interne werking van een Unit is niet van belang, alleen het resultaat wat hij oplevert. Als je bij de internals moet kunnen lijkt het me dat je de class niet goed opgezet hebt.

Wij hanteren standaard een code coverage van minimaal 80%, als je hier onder zit moet je wel een goede reden hebben (is ook zichtbaar in het nightly build overzicht), dat kan bijvoorbeeld als er veel gegenereerde code (proxies) is en ook frontends (asp.net webforms) hebben nog wel eens mindere coverage, al wordt de logica wel netjes gescheiden en goed getest.

Is 80% niet wat laag? Voor iets van een front-end kan ik het nog begrijpen ( Daar schrijven wij sowieso geen unit tests voor ), maar voor andere delen lijkt een veel hogere code coverage me wel wenselijk, anders zijn je unit tests verre van compleet en kun je nog niet uitgaan van een juiste werking bij een wijziging.

[ Voor 7% gewijzigd door Woy op 30-11-2011 09:25 ]

[Janoz]

Die percentages liggen ook heel erg aan het type project (en dan bedoel ik niet het deel). Als je een simpele YADF hebt kan het percentage best lager zijn, terwijl bij een project met meer business logic het percentage eerder hoger ligt. Daarnaast heb je natuurlijk ook nog of je je domain wel of niet meeneemt in de coverage berekening.

[SiErRa]

Woy schreef op woensdag 30 november 2011 @ 09:24:

Dat is iets wat je juist niet nodig hebt als je je code goed opgezet hebt, en de juiste mocks/stubs gebruikt. De interne werking van een Unit is niet van belang, alleen het resultaat wat hij oplevert. Als je bij de internals moet kunnen lijkt het me dat je de class niet goed opgezet hebt.

Hiermee bedoel ik alleen de manier om zo je mocks erin te schuiven, zodat je niet hoeft te injecten met constructor overloads of IOC frameworks.

Woy schreef op woensdag 30 november 2011 @ 09:24:
Is 80% niet wat laag? Voor iets van een front-end kan ik het nog begrijpen ( Daar schrijven wij sowieso geen unit tests voor ), maar voor andere delen lijkt een veel hogere code coverage me wel wenselijk, anders zijn je unit tests verre van compleet en kun je nog niet uitgaan van een juiste werking bij een wijziging.

Het is ook een minimum, maar het geldt eigenlijk wel voor alles. Je hebt natuurlijk altijd nog je eigen verantwoordelijkheid als ontwikkelaar om te zorgen dat je je werk ook goed test al zit je project al dik over die 80% heen. Unittesting in frontends vind ik overigens wel heel belangrijk, let maar eens goed op waar de meeste defects op komen, en dat zijn lang niet altijd op grafische details.

[Verwijderd]

Wat korte opmerkingen om de discussie in leven te houden:

Er is een verschil tussen 'Unit tests' en 'Integration tests'.

Unit tests zijn tests voor specifieke (voornamelijk) kléine units van code.
Op het moment dat je tijdens het schrijven van een unit test er niet uit komt met al je stubs / mocks / asserts, kan dat een teken zijn dat je een te grote unit in één keer aan het testen bent.

Denk hierbij ook aan het SRP (Single Responsibilty).

Stel je test een 'OrderController', welke afhankelijkheden heeft van een IOrderService, ICartService, IStockService, IMailService, ICatalogService, etc.

- plaatsen van een order
- betalen van een order
- verifieren van een order betaling
- order status mailtjes
- afboeken van vooraad, etc. etc.

Wil je nu tests schrijven voor je OrderController, dan kan je al snel in de knoop raken omdat je ordercontroller veel te veel depencies heeft (veel mocks/stubs, etc). Wat weer komt omdat die éne controller ook veel te veel verantwoordelijkheden heeft.

Splits het op in kleinere controllers (units) met minder externe dependencies. Wat je unit tests dus ook weer kleiner, leesbaarder en beheersbaar houdt.

[Grijze Vos]

Soms heb je gewoon een softwarelaag die de spil is tussen een aantal verschillende componenten. In zo'n geval is het juist handig om stubs te hebben voor die andere componenten, om jouw ene componenet is isolatie te testen.

[Hydra]

Waster schreef op dinsdag 22 november 2011 @ 17:07:
Wordt in de praktijk ook echt zo ver gegaan en iedere class in isolatie ge-unit test?

Wij leveren een API aan klanten, vrij uitgebreid (honderden klassen) en elke class die publiek beschikbaar is (en de meeste die dat niet zijn) heeft een test-klass. Iedere public method in die classes heeft ook weer minstens een unittest. Het is een flinke hoeveelheid werk, maar het betaalt zich gewoon terug. Je vangt enorm veel nieuw geintroducerde bugs af door gewoon een jUnit testrun te starten. Het is erg kortetermijn denken dat dergelijke tests schrijven 'teveel tijd kosten'. Tuurlijk, het is haast nog saaier dan documenteren, maar het moet gebeuren.

RobIII schreef op dinsdag 22 november 2011 @ 18:26:
Het is natuurlijk afhankelijk van hoe je werkt maar doorgaans schrijf je éérst de test(s) en dan pas de implementatie.

LOL

[Verwijderd]

Verwijderd schreef op dinsdag 06 december 2011 @ 09:34:
Wat korte opmerkingen om de discussie in leven te houden:

Er is een verschil tussen 'Unit tests' en 'Integration tests'.

Unit tests zijn tests voor specifieke (voornamelijk) kléine units van code.
Op het moment dat je tijdens het schrijven van een unit test er niet uit komt met al je stubs / mocks / asserts, kan dat een teken zijn dat je een te grote unit in één keer aan het testen bent.

Denk hierbij ook aan het SRP (Single Responsibilty).

Stel je test een 'OrderController', welke afhankelijkheden heeft van een IOrderService, ICartService, IStockService, IMailService, ICatalogService, etc.

- plaatsen van een order
- betalen van een order
- verifieren van een order betaling
- order status mailtjes
- afboeken van vooraad, etc. etc.

Wil je nu tests schrijven voor je OrderController, dan kan je al snel in de knoop raken omdat je ordercontroller veel te veel depencies heeft (veel mocks/stubs, etc). Wat weer komt omdat die éne controller ook veel te veel verantwoordelijkheden heeft.

Splits het op in kleinere controllers (units) met minder externe dependencies. Wat je unit tests dus ook weer kleiner, leesbaarder en beheersbaar houdt.

Een controller zou ik niet unit testen; veelal is de controller niet erg samenhangend; deze opsplitsen in diverse bestanden vermenigvuldigd het aantal bestanden, introduceert code overhead en verschuift het probleem alleen maar. Een controller hoort een zwik afhankelijkheden te verbindAls je controller uit vele honderden regels bestaat is het een logische stap, maar dan is het waarschijnlijk dat de controller meer doet dan alleen maar lijmen of het meerdere delen van je model benaderd.
Met de annotatie-shortcuts van diverse frameworks tegenwoordig kun je zelfs lege controller methoden krijgen terwijl die veel werk uit handen nemen; maar niet langer in code. Zelf moet de controller niet een zodanige body hebben dat unit testen veel zin heeft.
Ik zou voorstellen als alternatief een automatische functionale test te schrijven, deze is in het geval van een controller veel meer waard dan een unit test.

[Grijze Vos]

Een controller in bijv. asp.net mvc3 is prima te unit testen, ik zie het probleem niet zo.

[Verwijderd]

Grijze Vos schreef op vrijdag 23 december 2011 @ 20:47:
Een controller in bijv. asp.net mvc3 is prima te unit testen, ik zie het probleem niet zo.

Als je niet vervalt in het maken van 'fat' controllers.

Voorbeeld: http://nopcommerce.codepl...rs%2fCatalogController.cs

Dit is zooo lelijk, en zo lastig te testen.

Bovenstaande controller is een duidelijk voorbeeld van een fat controller welke makkelijk opgesplits kan worden in controllers zoals 'ProductListController SingleProductController ProductSearchController etc).
In dit geval is het asp.net mvc, dus refactoren naar een Area lijkt me ook wel zinvol.

[Avalaxy]

Zo dan, dat is een flink uit de hand gelopen controller

[Ryur]

Verwijderd schreef op woensdag 28 december 2011 @ 14:30:
[...]


Als je niet vervalt in het maken van 'fat' controllers.

Voorbeeld: http://nopcommerce.codepl...rs%2fCatalogController.cs

Dit is zooo lelijk, en zo lastig te testen.

Bovenstaande controller is een duidelijk voorbeeld van een fat controller welke makkelijk opgesplits kan worden in controllers zoals 'ProductListController SingleProductController ProductSearchController etc).
In dit geval is het asp.net mvc, dus refactoren naar een Area lijkt me ook wel zinvol.

Die code is gewoon een perfect voorbeeld van hoe het NIET moet!
Krijg er waarschijnlijk vannacht een nachtmerrie over

[Grijze Vos]

Verwijderd schreef op woensdag 28 december 2011 @ 14:30:
[...]

Alleen opsplitsen maakt hem niet veel testbaarder lijkt me. Dat ding is hard toe aan wat seperation of concerns.

[ZpAz]

Zelf heb ik al meerdere keren gekeken naar Unit Testing. Maar echt duidelijk wordt het niet. Wat test je bijvoorbeeld allemaal? Bij classes en methode's die een waarde teruggeven is het testen nog wel te doen. (Wat ongeveer de hele Model kant afvangt van MVC lijkt mij). Maar hoe doe je dat dan met controllers die tegen een view zeggen dat ze iets moeten aanpassen bijvoorbeeld?

Want stel je voor je hebt de volgende code:
Letterlijk de queries gedaan voor de sake of simplicity

Java:

class producten
{
    
    public int getProductCountForType(string type)
    {
        return this.db.select("select COUNT(id) FROM producten WHERE type=" + type);
    }
    
    public boolean addProduct(type, name, price)
    {
        return this.db.insert("INSERT INTO producten (type, name, price) VALUES(" + type + "," + name + "," + price ")");
    }
    
    public DB getDb()
    {
        return this.db();
    }
}

En je wilt hier een test voor schrijven dan zou ik zoiets doen, correct?

Java:

class testProducten
{
    
    protected producten;
    
    public void setUp()
    {
        this.producten = new Producten();   
        this.producten.getDb().query("INSERT INTO producten (type, name, price) VALUES('stoelen','blauw lederen stoel',100)");
    }
    
    public void tearDown()
    {
        this.producten.getDb().query("TRUNCATE producten");
    }
    
    public int testGetProductCountForType()
    {
        //Non existing type
        this.assertEquals(0, this.producten.getProductCountForType("nonexisting");
        //Exisiting type
        this.assertEquals(1, this.producten.getProductCountForType("stoelen");
    }
    
    public void testAddProduct()
    {
        this.producten.addProduct("stoelen", "rode leren stoel", 150);
        this.assertEquals(2, this.producten.getProductCountForType("stoelen");
    }
    
}

Is dit correct, of zit ik nu compleet verkeerd te denken.

Voorbeeld is Java, maar concepten van Unit Testing zijn natuurlijk toepasbaar in een scala aan talen.

edit:

Als ik deze code bekijk heb ik het gevoel dat die unit tests niet de daadwerkelijke code testen maar enkel de mocks, daar ontgaat het nut mij van.

[ Voor 6% gewijzigd door ZpAz op 04-02-2012 14:20 ]

[Herko_ter_Horst]

Lijkt me op zich correct (behalve dan dat je die database waarschijnlijk niet wilt exposen).

Je wilt checken dat methoden doen wat ze beloven. Nu is dat zonder ontwerp/documentatie niet altijd triviaal afleidbaar uit de naam van de methode. In dat geval kan de test ook dienst doen als documentatie van de aannames (wat gebeurt er bijvoorbeeld als je bijvoorbeeld "null" meegeeft als type?), dus het dwingt je wel de juiste vragen te stellen.

Om te testen of een controller op basis van updates in het model de juiste info doorgeeft aan een view (of meer algemeen: of een class op de juiste wijze interacteert met een andere class), kun je gebruik maken van mock-ups. Deze mock-ups zijn zo simpel mogelijk en alleen bedoeld om het gedrag van de te testen class te verifieren. Er zijn voor diverse talen mock-up tools beschikbaar (voor Java o.m. jMock en Mockito), maar je kunt ook zelf een simpele test-class schrijven.

[ Voor 4% gewijzigd door Herko_ter_Horst op 04-02-2012 14:36 ]

[ZpAz]

Herko_ter_Horst schreef op zaterdag 04 februari 2012 @ 14:34:
Lijkt me op zich correct (behalve dan dat je die database waarschijnlijk niet wilt exposen).

Je bedoelt aan de test klasse? Want hoe anders zorg ik er bijvoorbeeld voor dat er in de database de juiste informatie staat. Dan kan je wel een "mock klasse" maken die de database simuleert, maar dan zit je die mock klasse te testen en niet de klasse die de verbinding naar de database heeft toch?

[Herko_ter_Horst]

De class Producten is voor jouw systeem de interface naar de informatie. Dat er een DB achter zit, is niet interessant. Wat je aan de buitenkant wilt weten, is wel wat jij in je unit test hebt gestopt: als ik een addProduct doe, moet daarna de getProductCount 1 hoger zijn.

In dit geval is jouw Producten class zo'n vreselijk dun laagje om de DB, dat het nauwelijks testwaardig is zonder echte DB (waarbij ik maar even aanneem dat DB een externe API is, zoals Hibernate of JDBC). Wat je niet moet gaan doen, is unit testen of zo'n externe library z'n werk goed doet.

Als jij wilt testen of Producten de juiste query opbouwt voor je DB, kun je DB mocken en daarmee testen op de queries die Producten gebruikt om de DB aan te roepen. En als DB slechts de interface is naar een andere component die ook nog in ontwikkeling is, kun je altijd nog besluiten DB te mocken om voor bekende input de verwachtte resultaten op te leveren.

[ Voor 16% gewijzigd door Herko_ter_Horst op 04-02-2012 14:56 ]

[Kettrick]

Herko_ter_Horst schreef op zaterdag 04 februari 2012 @ 14:49:
De class Producten is voor jouw systeem de interface naar de informatie. Dat er een DB achter zit, is niet interessant. Wat je aan de buitenkant wilt weten, is wel wat jij in je unit test hebt gestopt.

In dit geval is jouw Producten class zo'n vreselijk dun laagje om de DB, dat het nauwelijks testwaardig is zonder echte DB (waarbij ik maar even aanneem dat DB een externe API is, zoals Hibernate of JDBC). Wat je niet moet gaan doen, is unit testen of zo'n externe library z'n werk goed doet.

Eens, in mijn huidige project zie ik constructies die het volgende doen :

code:

$consumer -> fooService.findAll()->fooDao.findAll()->enitiManager.findAll(Foo);

Waarbij "omdat het kan/moet" maar door lagen gebouwd worden, uiteraard hebben de service en dao maar 1 regel code, en wordt deze regel code ook keurig gemockt in de unit tests. Ook heb hibernate stuk wordt getest of hibernate echt wel alles teruggeeft .

Het unittesten van one-liners is wat mij betreft volkomen onzinnig en gebeurd bij ons alleen maar om de code coverage boven 80% te houden

Als jij wilt testen of Producten de juiste query opbouwt voor je DB, kun je DB mocken en daarmee testen op de queries die Producten gebruikt om de DB aan te roepen.

^^

[Herko_ter_Horst]

Kettrick schreef op zaterdag 04 februari 2012 @ 14:56:

^^

De vraag is overigens wel hoe zinnig het testen van specifieke queries is... In dit voorbeeld zijn het triviale queries die wel bijna altijd op dezelfde manier opgebouwd zullen worden, maar in meer ingewikkelde gevallen zijn er natuurlijk meerdere queries die hetzelfde resultaat opleveren. Dan is het maar de vraag of je wilt checken op de specifieke query. Maar goed, dunne database-abstractielaagjes zijn niet de beste use-case voor unit tests.

M.i. zijn unit tests vooral bedoeld om contracten te checken: doen componenten/classes/methodes wat ze beloven. Door alle gerelateerde zaken te mocken met voorspelbare waarden, kun je een component in isolatie testen.

[Kettrick]

Herko_ter_Horst schreef op zaterdag 04 februari 2012 @ 15:12:
M.i. zijn unit tests vooral bedoeld om contracten te checken: doen componenten/classes/methodes wat ze beloven. Door alle gerelateerde zaken te mocken met voorspelbare waarden, kun je een component in isolatie testen.

Hier zie ik veel collega's ook de fout mee in gaan. In plaats van het mocken worden grote delen van applicaties in testcases opgezet, met als resultaat dat elke kleine change in onderdeel x een testcase van een totaal ongerelateerd onderdeel doet falen .

De discusses "wat is een unittest/integratietest" komt op de meeste afdeling op zijn minst eens per paar maanden voorbij .

Wat mij betreft is alles wat meer doet dan 1 klasse testen een integratie test, die je in veel gevallen los zet van unittests en schrijft met een andere opzet.

[ZpAz]

Ik heb nu van een aantal producten (Sequel Pro, VLC, VirtualBox) de Source Code gedownload. Maar het aantal unit tests wat hier in voor komt komt nogal weinig over in vergelijking bij de totale code van het product (snel doorgekeken). Bij lange na wordt zeker niet elke klasse ge-unit-test.

Wat is nu gebruikelijk om wel of niet te unit-testen? Ik denk dat dat misschien meer de essentie van mijn vraag is.

[Herko_ter_Horst]

Ik zou zeggen dat je "units" moet unit testen . Wat een zinnige "unit" is, hangt af van de applicatie. De ene keer is dat een component, de andere keer een losse class. Hoe ingewikkelder de code, hoe meer kans dat je die code in isolatie wilt testen.

Wat je in elk geval wilt testen, zijn de contracten die een component of class aanbiedt aan de rest van de applicatie / de rest van het systeem.

[ZpAz]

Wat je in elk geval wilt testen, zijn de contracten die een component of class aanbiedt aan de rest van de applicatie / de rest van het systeem.

Wat bedoel je hiermee? Zou je een voorbeeld kunnen geven?

[Herko_ter_Horst]

Wat ik bedoel is dat je voor tests vooral geïnteresseerd bent in wat een component of class doet en niet zozeer in hoe die het klaarspeelt.

Dus stel dat je een class hebt die de Comparable interface implementeert:

Java:

public class Foo implements Comparable<Foo> {
public int compareTo(Foo otherFoo) {
 return FooComparisonHelper.compare(this, otherFoo);
}

Java:

/* not public */ class FooComparisonHelper {
 /* not public */ static int compare(Foo oneFoo, Foo otherFoo) {
  return whateverItTakesToCompareOneFooToAnother;
}

In dit geval is het van groot belang om Foo te unit testen, aangezien deze class de interactie verzorgt met de rest van het systeem. Je wilt dus verifieren dat Foo de compareTo method goed implementeert. Het is niet zozeer van belang om FooComparisonHelper te unit testen, omdat deze toch niet van buiten aangeroepen wordt.

In dit geval zie ik dus Foo i.c.m. FooComparisonHelper als een "component" die ik ter beschikking stel. Foo bevat het contract dat ik afspreek met de rest van de applicatie, FooComparisonHelper niet.

[ZpAz]

Zou je niet juist willen testen of "FooComparisonHelper" de juiste waardes teruggeeft bij verschillende te vergelijken items?

[Herko_ter_Horst]

In eerste instantie niet.

Ik ben vooral geïnteresseerd in of Foo het goed doet, dat is namelijk het ding dat voor problemen kan zorgen in de rest van de applicatie. FooComparisonHelper kan alleen "lokaal" voor problemen zorgen.

[ZpAz]

Maar wil je met unit testing niet juist "lokale problemen" testen? Dat is immers waarom je een Mock zou schrijven om in je test niet afhankelijk te zijn van een ander stuk code. Of zit ik hier compleet naast.

[Herko_ter_Horst]

Nee, je wilt geen lokale problemen testen. Je wilt verifiëren dat units doen wat je van ze verwacht.

In dit geval zijn Foo en FooComparisonHelper onlosmakelijk met elkaar verbonden: er is geen manier om in je test FooComparisonHelper te mocken. Ze zijn dus één unit/component. Van een unit is de publieke interface (het contract) interessant. De rest is implementatiedetail.

Als ik de code zou veranderen in:

Java:

public class Foo implements Comparable<Foo> {
public int compareTo(Foo otherFoo) {
return whatEverItTakesToCompareThisFooAndOtherFoo;
}

is de unit test voor Foo nog steeds interessant. Een unit test voor FooComparisonHelper is dat niet (nog los van of je FooComparsonHelper weggooit of in stand houdt).

[djluc]

Ik probeer het zo praktisch mogelijk te maken, dus in real world te verwachten situaties, bijvoorbeeld even wat simpele test code:

PHP:

<?PHP

class MPing extends Measurement {
    
    public function check($host, $port=80) {
        $timeout=0.1;
        $tB = microtime(true); 
        @$fP = fsockopen($host, $port, $errno, $errstr, $timeout); 
        if (!$fP) { return false; } 
        $tA = microtime(true); 
        return true; 
    }
}


class TestOfPing extends UnitTestCase {
    
    function testGoogle() {
        $MPing=new MPing();
        $this->assertTrue($MPing->check('google.com'));
    }
    
    function testNonExistingDomain() {
        $MPing=new MPing();
        $this->assertFalse($MPing->check('jldfsafajsdlfdsjfdas.nl'));
    }
    
    function testIpCorrect() {
        $MPing=new MPing();
        $this->assertTrue($MPing->check('94.247.4.117'));
    }
}

Er is dus een functie die blijkbaar een ping commando doet. Dat zou op diverse manieren geïmplementeerd kunnen worden. Het zou de huidige implementatie kunnen zijn maar net zo goed een exec() of wat dan ook.

Dat is echter niet relevant om te testen. Enige wat ik wil dat die class doet is mij het juiste antwoord geven, is de host bereikbaar of niet? Dus schrijf ik zowel positieve als negatieve tests die dat voor me controleren.

Voorbeeld uitbreiding: We gaan over naar IPv6. Wat doe ik dan: 2 nieuwe tests toevoegen waarbij ik de functie aanroep met een IPv6 adres. Vanaf dat moment is duidelijk of dat wel- of niet werkt en moet er eventuele andere code geplaatst worden.

[Herko_ter_Horst]

Dit is wel een tricky voorbeeld, omdat een ping bijzonder slecht te unit testen is zonder het internet te mocken.

Het doel van unit tests (i.t.t. integratie- en acceptatietests) is juist om te testen met zo min mogelijk externe afhankelijkheden. Je bent nu afhankelijk van: de implementatie van fsockopen(), je DNS instellingen, je internetverbinding, Google, jldfsafajsdlfdsjfdas.nl en de machine met IP 94.247.4.117 en of op al die machines poort 80 wel of niet open is.

Wat als je internetverbinding er uit ligt? Of de DNS van je provider? Wat als iemand jldfsafajsdlfdsjfdas.nl registreert? Het falen van deze tests geeft helemaal geen indicatie over de correctheid van jouw code.

Als je dit wat meer robuust wilt testen, dan zul je een controleerde netwerkomgeving op moeten zetten waar een aantal hosts zeker wel of niet bestaan en voorspelbaar wel of niet poort 80 open hebben.

Maar we praten dan zeker over integratie- zo niet acceptatietests, niet over unit tests.

[ Voor 26% gewijzigd door Herko_ter_Horst op 04-02-2012 17:20 ]

[djluc]

Klopt, helemaal gelijk wat dat betreft. Er zitten een aantal assumptions in. In dit geval wordt het gebruikt als monitoring dus is het überhaupt nutteloos als internet niet werkt. Een test netwerkomgeving hiervoor gaat wat ver.

Voor de test kunnen we inderdaad gewoon intern pingen maar die IP adressen hier vermelden gaat niet. Het internet mocken lijkt me ook geen goed plan dus daarom voldoet dit op zich prima in deze case.

Waar het me echter meer om gaat is dat het laat zien dat je geen vage dingen hoeft te testen, gewoon het publieke gedeelte testen met diverse vormen van input en je verwachting er bij. Dat geeft al snel een goed beeld van of iets niet of juist wel werkt. De implementatie is niet relevant voor de test, alleen het juiste antwoord.

Ik merk dat met name de negatieve case erg belangrijk is. Vaak wordt een error niet goed verwerkt of wat dan ook. Daar zie je vaak dat de test je meer bewust maakt van het afvangen van alle opties.

[Verwijderd]

Wat ook heel veel mensen vergeten is dat UNIT tests (dus niet integration tests / acceptence tests) geschreven moeten worden VOORDAT er echte code geschreven wordt.

begin met je unit test !

Dit zorgt er voor dat er dus (zowat) geen productie code is, zonder een unit test.
Want: productie code vloeit voort uit het schrijven van je unit test.

Ik probeer zo veel mogelijk de volgende workflow aan te houden:

- Schrijf unit test
- implementeer structuur van de code (om het te laten compileren, dus alleen class definities met NotImplementedExceptions / return null / etc)
- Run tests (alles faalt)
- implementeer logica
- Run tests
- etc.

Met achteraf UNIT tests implementeren loop je bijna 100% zeker tegen problemen op, omdat je toch je class en/of functie zo hebt geschreven dat het niet meer testbaar is.

Over het mocken van Databases e.d.:
Ik probeer zelf altijd zo min mogelijk te mocken en zie mijzelf overigens ook steeds minder Unit tests schrijven, maar steeds meer BDD integration tests.

Dit zorgt ervoor dat je niet oneindig veel mocks en stubs zit te schrijven, en de meeste (goede) test frameworks kunnen prima i.c.m. een live (test) database werken.
In je test / fixture setup zorg je dat je database gevuld is met de juiste test data.

[BikkelZ]

Ik vind Unit Tests gewoon sneller ontwikkelen bij sommige goed afgekaderde delen van de code. Het is simpelweg veel sneller dan iedere keer een hele GUI opstarten en als je genoeg edge cases definieert dan raak je iedere keer alle uitzonderingen die maar kunnen voorkomen. Sterker nog, door edge cases te bedenken voor je Unit Tests schrijft dwing je jezelf te focussen op de risico's die zich mogelijk in je code gaan voordoen.

Echter zijn er ook dingen zoals Workflows, om die te testen moet je toch een soort van scenario's gaan testen. Is dat dan weer Integration Testing officieel? Ik zou zeggen dat je korte functies hebt die één ding doen, die allemaal afzonderlijk unit test, en dan vervolgens de grotere functies die meerdere subroutines aanroepen gaat testen, om vervolgens wat user stories te testen door alle calls vanuit een UI te simuleren en zo je mogelijke happy flows en exceptions een keer te triggeren.

Want ook de juist Exception throwen op het juiste moment is natuurlijk juist iets wat je moet testen

[ Voor 62% gewijzigd door BikkelZ op 13-02-2012 13:54 ]

[Verwijderd]

Voor iedereen die in Visual Studio werkt: Check dit project eens: NCrunch

Werk er nu een weekje mee, en dit is voor mij nu al DÉ tool van 2012.

[Avalaxy]

Okee, vooruit dan maar weer.

[Grompie]

Verwijderd schreef op maandag 13 februari 2012 @ 23:28:
Voor iedereen die in Visual Studio werkt: Check dit project eens: NCrunch

Werk er nu een weekje mee, en dit is voor mij nu al DÉ tool van 2012.

Wauw ben sterk onder de indruk van deze tool! Topper, bedankt voor de tip!

[djluc]

BikkelZ schreef op maandag 13 februari 2012 @ 13:51:
Ik vind Unit Tests gewoon sneller ontwikkelen bij sommige goed afgekaderde delen van de code. Het is simpelweg veel sneller dan iedere keer ee
[...]

Klopt, dat verbaasde me ook maar het is echt zo. Met name omdat je niet meer na hoeft te denken over de individuele delen van de code aan de ene kant en alle aanroepen stukken duidelijker worden. Anders vallen ze niet te testen. De decoupling, het scheiden van delen van de code, stijgt ook enorm. Ook hier weer omdat testen anders knap lastig wordt. Dus al met al zijn dat best complexe verschillen die uiteindelijk de boel stukken eenvoudiger maken.

[BikkelZ]

Verwijderd schreef op maandag 13 februari 2012 @ 23:28:
Voor iedereen die in Visual Studio werkt: Check dit project eens: NCrunch

Werk er nu een weekje mee, en dit is voor mij nu al DÉ tool van 2012.

Zag er best nice uit, maar zie ineens 25/28 projecten die niet builden volgens NCrunch?

[Verwijderd]

BikkelZ schreef op dinsdag 14 februari 2012 @ 13:52:
[...]


Zag er best nice uit, maar zie ineens 25/28 projecten die niet builden volgens NCrunch?

Het blijft wel betá natuurlijk :-) waarschijnlijk heb je wat custom build steps die niet meewerken misschien? (of mis je toch wat handmatig gekopieerde dll's)
Ik geloof dat NCrunch je projecten naar een tijdelijke map verplaatst om daar geïsoleerd te kunnen draaien.

[BikkelZ]

Misschien ook niet het meest handige project om mee te beginnen denk ik ook....ken het ook nog niet door en door.