Vragen over unittesting

[hydrargyrum]

Beste tweakers,

Ik heb een paar vragen over unittesting:

• Wanneer schrijf je tests? Maak je eerst je tests en schrijf je je code dan zo dat hij eraan voldoet, of schrijf je je tests om te kijken of je code doet wat je ervan verwacht, en ga je vervolgens je code zo aanpassen dat je tests slagen?
• Hoe weet je dat je alle mogelijke scenario's gehad hebt? Het lijkt me vrij makkelijk, vooral in een omgeving met veel functies.
• Misschien niet geheel relevant, maar wat is het nut/voordeel van continuous intergration? Hoe het werkt snap ik, maar wat is er fijn/goed aan?

[Croga]

1. Wanneer? Wanneer je wilt! TDD gaat uit van test eerst, andere methoden weer van test laatst. Het één is niet persé beter dan het ander.

2. Je weet dat je alle mogelijke scenarios gehad hebt als je uit gegaan bent van de functionaliteit van het systeem, niet van de unit. Proberen 100% test coverage op de unit te krijgen is waste en moet je dus niet doen. Dit is overigens ook een reden waarom TDD een enorme valkuil heeft; als je alle tests van te voren schrijft loop je het risico code te schrijven die in de praktijk nooit geraakt gaat worden; wederom waste.

3. Het voordeel van continuous integration is te zien in punt 2. Het zorgt er voor dat unit tests (gedeeltelijk) overbodig worden omdat je het systeem kunt testen. En uiteindelijk is dat het enige wat interessant is; de unit zal nooit op zichzelf gebruikt gaan worden. Daarnaast zorgt continuous integration er voor dat je op ieder willekeurig moment live kunt gaan zonder iets te breken.

[jip_86]

1: Wat je leuk vind. Je kan ze eerst schrijven, wat ook wel bekend is als TDD. Je kan ze ook achteraf maken om later te kunnen verifiëren dat het ook blijft werken bij latere aanpassingen. Als je ergens een bugfix doet kan het zijn dat een eerdere functionaliteit omvalt.

2: Als je al een omgeving hebt zonder unittests kun je dat volgens mij bijna niet weten. Bij ons worden ze nu vaak toegevoegd om te kunnen verifiëren dat bij bugfixes gedane aanpassingen in de toekomst ook nog blijven werken. Wat Croga ook zegt, het is erg lastig om alles af te dekken.

3: Bij continuous integration kan je die unittests steeds laten draaien als onderdeel van de build. Zo zie je ook direct of code van een collega niet jouw code sloopt oid

[NMe]

Croga schreef op dinsdag 12 mei 2015 @ 17:35:
Daarnaast zorgt continuous integration er voor dat je op ieder willekeurig moment live kunt gaan zonder iets te breken.

Niet helemaal waar natuurlijk. Zelfs met een volledige code coverage test je alsnog alleen de units an sich en slechts in beperkte mate de samenwerking met andere delen van het systeem. Het zorgt er in elk geval wel voor dat je geen echt obvious fouten overhoudt.

[Amanush]

*fanboy reactie*
Take my advice, en pas alsjeblieft TDD toe. Schrijf tests van te voren, en daarna pas de functie. Dat zorgt (volgens mij) voor het meest kwalitatieve `stuk code`. Het laat je nadenken over zowel de input als output van functies.

[ Voor 15% gewijzigd door Amanush op 12-05-2015 18:03 ]

[NMe]

Amanush schreef op dinsdag 12 mei 2015 @ 18:03:
*fanboy reactie*
Take my advice, en pas alsjeblieft TDD toe. Schrijf tests van te voren, en daarna pas de functie. Dat zorgt (volgens mij) voor het meest kwalitatieve `stuk code`.

Het meest kwalitatieve stukje code denk ik niet. Je zorgt wel voor goede code coverage van je tests zonder dat je daar echt moeite voor hoeft te doen, en je dwingt jezelf om te denken in de richting van "hoe wil ik dat deze code gebruikt wordt?" in plaats van "wat moet deze code doen?" wat op zichzelf een waardevolle insteek is.

[gekkie]

Denk dat het vooral belangrijk is dat de test goed is .. en niet alleen het gewenste resultaat bij een verwachte input / omstandigheden levert, maar vooral ook test hoe je code omgaat met onverwachte input / omstandigheden.

En denk ook dat het dus belangrijk is om in enige iteraties zowel je code als je test aan te blijven passen aan je wijzigingen en nieuw opgedane inzichten.

[Amanush]

Daarnaast is TDD effectiever tegen bugs dan het praten tegen eenden.

[NMe]

Amanush schreef op dinsdag 12 mei 2015 @ 18:10:
Daarnaast is TDD effectiever tegen bugs dan het praten tegen eenden.

Ook niet helemaal waar. Je voorkomt doordat je vanaf het eerste moment overal een unit test voor hebt natuurlijk wel een aantal bugs, maar bugs die voortkomen uit het samenwerken van twee stukjes code die je niet alszodanig getest hebt ga je er niet mee terugvinden. Zeker spul dat afhankelijk is van data uit een database of spul dat multithreaded met elkaar samenwerkt kan nog steeds onverwachte problemen opleveren waardoor je alsnog tegen je eendje moet praten.

[rinkel]

Er zijn idd verschillende manieren om met tests om te gaan.

Ik ben een voorstander van: test eerst, dan code.
Dit zorgt er voor dat je tijdens het schijven van de test goed nadenkt over de uitkomst van je code. Het moet immers ergens aan voldoen. En het zorgt, meestal, voor kleine methods die slechts een taak vervullen.
Daarnaast zorg je voor een hoge testcoverage als je er vanaf begin af aan mee begint.

Het nadeel vind ik soms dat in sommige gevallen de test complexer is dan de code. Dan schiet het een beetje z'n doel voorbij.

[gekkie]

NMe schreef op dinsdag 12 mei 2015 @ 18:19:
[...]

Ook niet helemaal waar. Je voorkomt doordat je vanaf het eerste moment overal een unit test voor hebt natuurlijk wel een aantal bugs, maar bugs die voortkomen uit het samenwerken van twee stukjes code die je niet alszodanig getest hebt ga je er niet mee terugvinden. Zeker spul dat afhankelijk is van data uit een database of spul dat multithreaded met elkaar samenwerkt kan nog steeds onverwachte problemen opleveren waardoor je alsnog tegen je eendje moet praten.

Timing related issues zijn helemaal briljant .. opzich zou het wel kunnen .. als je elke regel volstrekt paranoia gaat coden. Alle variablen op alles testen en alle potentiele fouten afvangen, in elke functie weer opnieuw, om je eigen programmeerfouten te voorkomen ..

Maar goed dan ligt al snel je performance weer op z'n gat ..

[Croga]

NMe schreef op dinsdag 12 mei 2015 @ 17:56:
Niet helemaal waar natuurlijk. Zelfs met een volledige code coverage test je alsnog alleen de units an sich en slechts in beperkte mate de samenwerking met andere delen van het systeem. Het zorgt er in elk geval wel voor dat je geen echt obvious fouten overhoudt.

Daar heb je zonder meer een punt. Je hebt meer nodig dan alleen continuous integration om op ieder moment live te kunnen gaan. Ik ging uit van de Spotify case maar daar is ook een configuratie deel nodig om volledige flexibiliteit te geven.

Overigens maakt James Coplien een zeer sterke case tégen TDD (edit: en de toevoeging...). Veel unit tests zorgen, vooral in combinatie met TDD, voor code die geschreven is om de tests te dekken in plaats van de functie. En, zoals gesteld, dat is waste. Dat is code die in de praktijk nooit geraakt gaat worden en dus tijd besteed die geen waarde levert.

Wellicht is TDD beter dan rubber duck testing maar daar zit nog een enorme berg ruimte tussen....

[ Voor 3% gewijzigd door Croga op 12-05-2015 18:37 ]

[NMe]

gekkie schreef op dinsdag 12 mei 2015 @ 18:33:
[...]

Timing related issues zijn helemaal briljant .. opzich zou het wel kunnen .. als je elke regel volstrekt paranoia gaat coden.

Dan ben je er nog niet in een multithreaded systeem dat afhankelijk is van user input. Het zou de eerste keer niet zijn dat ik ergens niet helemaal thread safe bezig ben en daarom pas in een laat stadium uitvind dat mijn applicatie bijvoorbeeld geheugen lekt. Daar beschermt geen enkele unit test je tegen.

Croga schreef op dinsdag 12 mei 2015 @ 18:34:
Veel unit tests zorgen, vooral in combinatie met TDD, voor code die geschreven is om de tests te dekken in plaats van de functie. En, zoals gesteld, dat is waste. Dat is code die in de praktijk nooit geraakt gaat worden en dus tijd besteed die geen waarde levert.

Nouja, belangrijker dan dat hij geen waarde levert is dat je er daadwerkelijk fouten mee kan introduceren. Als je code schrijft die je test dekt kun je zomaar een bepaalde vertakking van je code over het hoofd zien omdat je daar geen test voor geschreven hebt. Elke methode heeft wel voor- en nadelen en dat is natuurlijk precies de reden dat er nog steeds zo veel verschillende methodes bestaan.

[Avalaxy]

Amanush schreef op dinsdag 12 mei 2015 @ 18:03:
*fanboy reactie*
Take my advice, en pas alsjeblieft TDD toe. Schrijf tests van te voren, en daarna pas de functie. Dat zorgt (volgens mij) voor het meest kwalitatieve `stuk code`. Het laat je nadenken over zowel de input als output van functies.

Onzin. Als je zelf voor je eigen code de tests schrijft dan zie je dezelfde scenario's die je in je normale code over het hoofd ziet ook over het hoofd in je tests. Op die manier te werk gaan is puur schijnveiligheid. Het hoofddoel van unit tests is dan ook niet om te valideren dat je input/output klopt op het moment dat je het schrijft, maar om te controleren dat alles over verloop van tijd blijft werken zonder regressies.

[RobertMe]

Is het niet voornamelijk zo dat je moet doen waar je jezelf prettig bij voelt en waar je de tijd voor hebt/krijgt.

Bij simpele dingen zal ik niet snel de behoefte hebben om unit tests te schrijven. Een functie "save" die bv puur een specifieke entity omzet naar een INSERT/UPDATE query vind ik niet interessant en zal ik niet snel gaan testen. Code waar meer logica inzit (bv voorgaande voorbeeld met een generieke opzet, zeg een custom ORM lib) en meer een algoritme is vind ik testen weer juist wel heel belangrijk. Dat omdat het dus vaker gebruikt wordt, en wat complexer in elkaar zit en waarschijnlijk ook vaker onderhoud aan plaats vind. Dan is het wel belangrijk dat je op basis van een simpele test run weet dat de boel nog werkt.

Hoe weet je dat je alle mogelijke scenario's gehad hebt? Het lijkt me vrij makkelijk, vooral in een omgeving met veel functies.

Door de specs erbij te pakken en rand gevallen te testen "indien X lager dan 10 dan doe Y en anders Z", dan ga je dus testen met X = 9, X = 10 en X = 11. Iets wat voor een bestaand systeem natuurlijk onbegonnen werk is om allemaal na te lopen, maar bij een nieuw systeem/stuk functionaliteit kun je dit natuurlijk wel meteen zo testen. Daarnaast heb je natuurlijk nooit garanties, maar als er een bug is moet je daarvoor natuurlijk wel meteen een test schrijven. Makkelijkst is het daarbij dan ook om eerst de test te schrijven. Want dan kun je de test debuggen in plaats van dat je elke keer door de applicatie moet klikken. Daarnaast weet je dan ook meteen dat de bug is opgelost, de test slaagt immers.

Niet helemaal waar natuurlijk. Zelfs met een volledige code coverage test je alsnog alleen de units an sich en slechts in beperkte mate de samenwerking met andere delen van het systeem. Het zorgt er in elk geval wel voor dat je geen echt obvious fouten overhoudt.

Daarvoor kun je dan toch integratie tests schrijven die meedraaien? Mij lijkt het dan ideaal om ook een aantal tests te schrijven die units onderling testen, of evt. automatische functionele tests waarbij automatisch door de applicatie wordt geklikt. De randgevallen kun je dan testen met de unit tests, en het samenwerkende geheel op basis van de integratie/functionele tests. Beide/alle soorten tests zou je dan kunnen opnemen binnen de continuous intergration (daarmee dek je natuurlijk nog steeds niet de bugs af die toch optreden op basis van bepaalde data (uit bv database), of race conditions).

[gekkie]

NMe schreef op dinsdag 12 mei 2015 @ 18:46:
[...]
Dan ben je er nog niet in een multithreaded systeem dat afhankelijk is van user input. Het zou de eerste keer niet zijn dat ik ergens niet helemaal thread safe bezig ben en daarom pas in een laat stadium uitvind dat mijn applicatie bijvoorbeeld geheugen lekt. Daar beschermt geen enkele unit test je tegen.

Nah .. mijn TDD doet altijd @end goto start tests... mooi oneindig loopje .. als tie ooit crasht is het niet goed .. als tie blijft lopen .. dan weet ik het nog niet ... vang ik het wel mooi mee af !
(heb laatst wel de klant uitgelegd dat de first release nog oneindig op zich laat wachten .. maarja beter safe than sorry .... geloof dat tie iets mompelde van de betaling ook )

Achja zoals met alles is er geen heilige graal .. geen one fits all .. ook geen free lunch .. en meer van dat alles .. alleen common sense .. en vaak gaat dat goed .. en soms toch nog mis.

[ Voor 10% gewijzigd door gekkie op 12-05-2015 19:17 ]

[hydrargyrum]

Oke, bedankt voor alle inbreng over dit onderwerp. Ik ga dan eerst tests schrijven en dan code. Als ik het goed begrijp is het in mijn geval (web development) ook nuttig omdat ik dan eerst de backend kan doen en er dan pas een frontend aan kan maken?

Verder snap ik nu ook het voordeel van continuous intergration.

Zijn er verder nog dingen die ik moet weten over unittesting/TDD?

[BCC]

Zorg ervoor dat je tests zo snel mogelijk lopen. En kijk wat filmpjes van Corey Haines.

[NMe]

hydrargyrum schreef op dinsdag 12 mei 2015 @ 20:56:
Oke, bedankt voor alle inbreng over dit onderwerp. Ik ga dan eerst tests schrijven en dan code. Als ik het goed begrijp is het in mijn geval (web development) ook nuttig omdat ik dan eerst de backend kan doen en er dan pas een frontend aan kan maken?

Dat staat redelijk los van elkaar. Je schrijft bij TDD eerst je test, en dan pas de code die je wil testen. Of je dan eerst de backend gaat schrijven of eerst de frontend maakt niet heel veel uit, omdat je in beide gevallen hetzelfde model (de M uit MVC) aanspreekt. Voorlangs of achterlangs gaan je controllers met dezelfde dingen praten.

Dat gezegd hebbende vind ik het persoonlijk wel handiger om eerst de backend te maken en dan de frontend.

[pedorus]

Amanush schreef op dinsdag 12 mei 2015 @ 18:10:
Daarnaast is TDD effectiever tegen bugs dan het praten tegen eenden.

Hoezo? De effectiviteit van TDD in industriële studies is volledig onbewezen. Zie bijv. http://www.computer.org/c...013/06/tts2013060835.html Het is wel bewezen dat de productiviteit naar beneden gaat in industriële studies. Het lijkt me dus productiever om in de tijd die je niet aan TDD besteed je code aan een eendje uit te leggen, een groot deel van wat je uitlegt aan iemand anders onthou je en zo zie je misschien wat bugs.

Furthermore: One Hacker Way - Erik Meijer op 30:00

[gekkie]

Zou ook eerst de backend maken ja .. en opzich is een cli-testclient ook niet onhandig. Is over het algemeen ook makkelijker om er daar een hele berg van te spawnen om je backend ook wat te kunnen performance testen. (webtest frameworks zijn er ook wel .. maar goed spawn maar eens 1000 echte browsers tegelijk .. heb je een beste sloot geheugen nodig).

[Xepos]

Een tip: maak geen unit testen puur vanwege dat het aangeraden word. Kun je net zo goed je tijd besteden aan het debuggen achteraf.

Maak je test zodanig dat ook foute condities worden opgevangen.
Simpele voorbeeld:
Functie: 1+ a
Je test: functie(1) == 2 (Vaak houden mensen hierna op en denken dat ze klaar zijn)
FOUT
Test ook op randgevallen en onverwachte zaken zoals: functie(b) <-- kapot
of een minder opvallende: functie(0,5) als je int gebruikt krijg je gewoon 1 en niet 1,5

Als je ook op deze randgevallen test dan heb je pas echte unit testen. Die ook daadwerkelijk iets toevoegen.

[RobertMe]

Even een paar CLI testclients bouwen is natuurlijk wel erg afhankelijk van de taal die je gebruikt. In PHP zal het meer werk zijn dan een (herbruikbare) DLL in bv .NET. Maar in .NET zit je weer met het probleem dat je dan losse EXEs draait vs een groot ding (IIS) waarin je dingen wat efficiënter kunt aanpakken (in memory cachen bv, of eenmalig ophalen tijdens application start).

Of je aan front of backend begint is denk ik ook afhankelijk van wat je leuk vind etc. Als je meer een frontend man bent lijkt het mij dat je vanuit het frontend begint en daarna de logica gaat bouwen, en die dan kunt testen. Ben je meer een backend man dan is het testen ook meteen een mooie manier om ervoor te zorgen dat je uberhaupt een manier hebt voor het testen voordat je het frontend tegelijkertijd uit de grond moet trekken. Je moet immers een een manier hebben om de code te testen, dat kan of van front- tot backend alle zaken aan elkaar knopen zijn (en dan rond klikken) of de unit tests schrijven. Waarbij je bij de unit tests ook veel sneller kunt testen, omdat je niet elke keer opnieuw vanuit een startpunt door de applicatie hoeft te klikken (wat bij web een refresh in de browser kan zijn, maar bij Win./desktop moet je weer van voor af aan door de applicatie klikken, wat helemaal niet ideaal is).

[jip_86]

hydrargyrum schreef op dinsdag 12 mei 2015 @ 20:56:
Als ik het goed begrijp is het in mijn geval (web development) ook nuttig omdat ik dan eerst de backend kan doen en er dan pas een frontend aan kan maken?

Backend eerst is sowieso wel makkelijk omdat je dan gelijk al kan testen of de inrichting wel werkt bij het maken van de frontend

[gekkie]

RobertMe schreef op dinsdag 12 mei 2015 @ 21:49:
Of je aan front of backend begint is denk ik ook afhankelijk van wat je leuk vind etc. Als je meer een frontend man bent lijkt het mij dat je vanuit het frontend begint en daarna de logica gaat bouwen, en die dan kunt testen. Ben je meer een backend man dan is het testen ook meteen een mooie manier om ervoor te zorgen dat je uberhaupt een manier hebt voor het testen voordat je het frontend tegelijkertijd uit de grond moet trekken. Je moet immers een een manier hebben om de code te testen, dat kan of van front- tot backend alle zaken aan elkaar knopen zijn (en dan rond klikken) of de unit tests schrijven. Waarbij je bij de unit tests ook veel sneller kunt testen, omdat je niet elke keer opnieuw vanuit een startpunt door de applicatie hoeft te klikken (wat bij web een refresh in de browser kan zijn, maar bij Win./desktop moet je weer van voor af aan door de applicatie klikken, wat helemaal niet ideaal is).

Eigenlijk komt het bij mij altijd neer op iteraties waarbij backend en frontend worden afgewisseld, meestal eerst backend .. dan een functioneel soms beperkte (en niet fraaie) frontend .. en zo steeds verder uitbouwen. Met regelmatig tussentijds performance testen.
Maar over het algemeen steeds eerst een stuk backend ja. Maar dat zal wel door een techneuten form follows function komen.

[AlphaRomeo]

Xepos schreef op dinsdag 12 mei 2015 @ 21:49:
Een tip: maak geen unit testen puur vanwege dat het aangeraden word. Kun je net zo goed je tijd besteden aan het debuggen achteraf.

Helemaal mee eens.

Unit tests worden door sommige bedrijven enorm overrated. Een unit test is bedoeld om (de naam zegt het) een UNIT te testen, dus één kleine functie. Dit is geschikt voor functies met duidelijke input en output zoals wiskundige functies, string manipulation etc. In veel gevallen wordt een unit test echter ook ingezet als verkapte systeemtest waarbij eerst een half framework gestubt moet worden om de test überhaupt te kunnen draaien.

In sommige gevallen wordt een unit test lastig: bijvoorbeeld bij database-, filesystem- of netwerkcommunicatie. Dan moet je eerst een volledige laag gaan stubben, waarna je je weer kunt afvragen wat je nu eigenlijk aan het testen bent.

Het hangt af van de applicatie en de soort functie. Als je rakketten bouwt of een wiskundig framework is het anders dan wanneer je een desktopapplicatie bouwt. Tenzij je werkgever / projectmanager hier regels over heeft: besluit per functie of die wel of niet het testen waard is.

[Amanush]

Unit Tests zijn enorm handig om te doen waar ze bedoeld voor zijn. Mocht je iets breken, krijg je daar meteen melding van.

[Camulos]

AlphaRomeo schreef op woensdag 13 mei 2015 @ 12:58:
...
In sommige gevallen wordt een unit test lastig: bijvoorbeeld bij database-, filesystem- of netwerkcommunicatie. Dan moet je eerst een volledige laag gaan stubben, waarna je je weer kunt afvragen wat je nu eigenlijk aan het testen bent.
...

+1, zeker bij grotere en/of complexere software layers.. ga dan liever black-box testen of smoketesten. In plaats van unittesten zou je ook elkaar code kunnen reviewen.

[gekkie]

Camulos schreef op donderdag 14 mei 2015 @ 18:18:
[...]

+1, zeker bij grotere en/of complexere software layers.. ga dan liever black-box testen of smoketesten. In plaats van unittesten zou je ook elkaar code kunnen reviewen.

Of van alles een beetje .. in een linux kernel zit zo ongeveer wel alles ... unit/correctness tests .. men doet aan code review ... er draaien een berg build-tests .. random config tests .. fuzz tests .. en nog moet er een hoop gefixt worden en breek er elke kernel release wel het nodige (al was het maar omdat zaken waarmee geinterfaced wordt zich niet aan specs houden).

[NMe]

AlphaRomeo schreef op woensdag 13 mei 2015 @ 12:58:
[...]

Het hangt af van de applicatie en de soort functie. Als je rakketten bouwt of een wiskundig framework is het anders dan wanneer je een desktopapplicatie bouwt. Tenzij je werkgever / projectmanager hier regels over heeft: besluit per functie of die wel of niet het testen waard is.

Het hangt er vooraf vanaf hoe goed je betaald wordt. Of je raketten bouwt of de website van de lokale supermarkt maakt niet uit, hoe meer je betaald krijgt hoe meer tijd je kan steken in uitgebreid testen en CI.

Amanush schreef op donderdag 14 mei 2015 @ 14:55:
Unit Tests zijn enorm handig om te doen waar ze bedoeld voor zijn. Mocht je iets breken, krijg je daar meteen melding van.

Alweer zo'n onvolledige opmerking. Je krijgt helemaal niet altijd een melding als er iets breekt, zelfs niet als je 100% code coverage hebt voor je unit tests... Het enige waar een unit test je tegen beschermt is tegen regressie van stukken code waar je tests voor hebt geschreven. Daar heb je, zoals ik hierboven ook al zei, een heel groot deel van je problemen nog niet mee afgevangen. Spul dat afhankelijk is van je deployment. Spul dat afhankelijk is van threads in de eigen applicatie. Spul dat afhankelijk is van andere processen en systemen. Spul dat afhankelijk is van de stand van de sterren en de maan. Unit tests zijn niet heilig.

[ Voor 41% gewijzigd door NMe op 14-05-2015 19:44 ]

[Amanush]

NMe schreef op donderdag 14 mei 2015 @ 19:41:
[...]

Alweer zo'n onvolledige opmerking. Je krijgt helemaal niet altijd een melding als er iets breekt, zelfs niet als je 100% code coverage hebt voor je unit tests...

[...]

Oh, waarom schrijven we dan Unit Tests? Om meldinge te krijgen als iets *niet* breekt?

[NMe]

Amanush schreef op zaterdag 16 mei 2015 @ 21:07:
[...]

Oh, waarom schrijven we dan Unit Tests? Om meldinge te krijgen als iets *niet* breekt?

Om meldingen te krijgen als er iets breekt, ja. Maar dat wil niet zeggen dat je altijd als er iets breekt een melding krijgt. Het wil zeggen dat je een melding krijgt als je toevallig iets stuk maakt waar je op test. En zoals gezegd kun je niet overal op testen. Je weet wel, dat wat ik in de rest van die post die je wel heel selectief citeert ook al zei.

Unit tests zijn een hulpmiddel, meer niet. Ze zijn niet heilig.

[Ryur]

Amanush schreef op zaterdag 16 mei 2015 @ 21:07:
[...]


Oh, waarom schrijven we dan Unit Tests? Om meldinge te krijgen als iets *niet* breekt?

Ik ben helaas laat in het project waar ik nu aan werk begonnen met Unit Tests.

Wat ik nu doe: als er een bug optreed bij een gebruiker (in test/acceptatieversie nog!) dan schrijf ik een Unit Test om die bug te triggeren (en bedenk randvoorwaarden).
Dan ga ik de fix maken voor die bug.

Voordeel van deze manier is dat ik bij volgende fixes kan controleren of de eerder opgetreden bug niet weer de kop opkomt (dat de 'pleister' van de bug af is).

Dit houdt niet in dat mijn programma/project foutloos is! Ik heb er alleen voor gezorgd dat de bekende bugs niet meer optreden (en als ze wel optreden dat ik een melding krijg voordat het naar mijn gebruikers gaat).

Note: Ruby on Rails project, enige ontwikkelaar.

[gekkie]

NMe schreef op zaterdag 16 mei 2015 @ 22:02:
[...]

Om meldingen te krijgen als er iets breekt, ja. Maar dat wil niet zeggen dat je altijd als er iets breekt een melding krijgt. Het wil zeggen dat je een melding krijgt als je toevallig iets stuk maakt waar je op test. En zoals gezegd kun je niet overal op testen. Je weet wel, dat wat ik in de rest van die post die je wel heel selectief citeert ook al zei.

Unit tests zijn een hulpmiddel, meer niet. Ze zijn niet heilig.

Bij je auto doe je ook een APK .. op een beperkt aantal onderdelen .. met een beperkte wijze van onderzoek.
Als je geheel veilig wil rijden moet je overal trillingssensoren in stoppen .. in een mobiel röntgen apparaat gaan rijden want je weet maar nooit of er nog ergens metaal moeiheid is .. etc.
Met als gevolg dat je niet meer vooruit komt .. wat opzich wel het meest veilig is .. terwijl je een van de grotere veiligheidsrisico's van het rijden .. de mens wellicht over het hoofd weet te zien.

Moet je dan de APK maar afschaffen .. het is immers maar een momentopname .. en dan nog niet 100% proof. Nee het is een aardige tool .. kortom toch weer de 80-20-'regel' .. op het moment dat je ipv met 20% effort die 80% gaat oplossen .. maar met 80% effort die laatste 20% of minder probeert op te gaan lossen . is ook de kans dat je andere meer belangrijkere zaken over het hoofd gaat zien.

Maar voor die 20% effort 80% zekerheid .. bij goed toetsbare basisfunctionaliteit .. dan wel bij known issues, zoals de vorige spreker al aangaf .. is het zeker de moeite waard.

[ Voor 5% gewijzigd door gekkie op 17-05-2015 10:41 ]

[Amanush]

NMe schreef op zaterdag 16 mei 2015 @ 22:02:
[...]

Om meldingen te krijgen als er iets breekt, ja. Maar dat wil niet zeggen dat je altijd als er iets breekt een melding krijgt. Het wil zeggen dat je een melding krijgt als je toevallig iets stuk maakt waar je op test.

[...]

Zal wat zjn als je melding krijgt van dingen die breken waar je niet op test..

[NMe]

gekkie schreef op zondag 17 mei 2015 @ 10:39:
[...]

Moet je dan de APK maar afschaffen .. het is immers maar een momentopname .. en dan nog niet 100% proof.

Waar precies zeg ik dat unit tests slecht zijn? Ik zeg alleen dat ze niet heilig zijn. Amanush leek te suggereren dat je altijd een melding krijgt als er iets fout gaat in je code zolang je maar tests hebt, en dat is gewoon niet waar.

Amanush schreef op zondag 17 mei 2015 @ 10:41:
[...]

Zal wat zjn als je melding krijgt van dingen die breken waar je niet op test..

Je maakte de opmerking dat je altijd een melding krijgt als er wat stuk gaat. Dát is gewoon aantoonbaar onwaar en dát is waar ik op reageerde.

[gekkie]

NMe schreef op zondag 17 mei 2015 @ 13:18:
[...]
Waar precies zeg ik dat unit tests slecht zijn? Ik zeg alleen dat ze niet heilig zijn. Amanush leek te suggereren dat je altijd een melding krijgt als er iets fout gaat in je code zolang je maar tests hebt, en dat is gewoon niet waar.

Was ook meer een (mislukte) poging tot inhaken op jouw argumentatie. Het is proberen een balans te vinden tussen wanneer unittests je werkelijk kunnen helpen .. en wanneer je wellicht beter andere methoden kunt gebruiken om te proberen fouten te voorkomen. Alles heeft zo z'n voors en tegens en niets is perfect .. ook niet in combinatie met elkaar dek je nog niet 100% af .. als die garantie met een bepaalde (combinatie van) methode(n) er wel zou zijn anders zou er wel meer fout vrije software op de markt zijn (met enige mate van complexiteit .. i have seen none) ..

[Amanush]

NMe schreef op zondag 17 mei 2015 @ 13:18:
[...]

Je maakte de opmerking dat je altijd een melding krijgt als er wat stuk gaat. Dát is gewoon aantoonbaar onwaar en dát is waar ik op reageerde.

Ik merk het. Hoop dat je jezelf nog serieus neemt. Dit soort dingen zijn heel 'obvious', en ik denk niet dat jouw opmerkingen echt iets ophelderen..

[NMe]

Ik denk dat jouw opmerkingen zonder nuances toch echt een stukje verwarrender zijn.

[Croga]

gekkie schreef op zondag 17 mei 2015 @ 10:39:
Moet je dan de APK maar afschaffen .. het is immers maar een momentopname .. en dan nog niet 100% proof.

APK is inderdaad een heel mooie analogie....

Je monitort niet ieder stukje van de auto omdat dat meer moeite kost dan het oplevert. In plaats daarvan test je eens in de zoveel tijd de functionaliteit van de *auto* in plaats van van de *onderdelen*.

Op dezelfde manier zou je ook de functionaliteit van het *systeem* moeten testen, niet van de *unit*.

Net zoals het zinloos is om ieder onderdeeltje van de auto te testen, is het ook zinloos om ieder onderdeeltje van een systeem te testen. Niet alleen ben je veel tijd kwijt met het schrijven van unit tests, je bent ook nog eens meer aan het testen dan zinvol is. Daarnaast, en wellicht nog veel belangrijker: Waarom vertrouw jij de code die je schrijf voor de unit test meer dan de code die je schrijf voor de unit? Waar haal je de ilusie vandaan dat een unit test van betere kwaliteit is dan de unit? En mischien nog wel belangrijker: De denkfouten die je maakt in het schrijven van de unit maak je ook al in het schrijven van de unit test. En daarmee is de unit test dus waardeloos geworden.

[gekkie]

Croga schreef op zondag 17 mei 2015 @ 16:54:
[...]
APK is inderdaad een heel mooie analogie....

Je monitort niet ieder stukje van de auto omdat dat meer moeite kost dan het oplevert. In plaats daarvan test je eens in de zoveel tijd de functionaliteit van de *auto* in plaats van van de *onderdelen*.

Op dezelfde manier zou je ook de functionaliteit van het *systeem* moeten testen, niet van de *unit*.

Sommigen zaken montor je dan weer nagenoeg continu, of er dan nog sprake is van iets a la 'unittests' of meer sprake van code met "asserts" is de vraag. Bijvb bandenspanning .. airbag .. etc. al merk je ook daar dat een "goede test" misschien nog niet eens zo eenvoudig is .. mijn bandenspanningssensortoestand reageert pas bij 1.8 bar .. terwijl er normaalgesproken 2.2-2.4 in mag zitten, ik vind dat rijkelijk laat .. dus het vervangt in dit geval duidelijk geen handmatige test aan de pomp.

En mischien nog wel belangrijker: De denkfouten die je maakt in het schrijven van de unit maak je ook al in het schrijven van de unit test. En daarmee is de unit test dus waardeloos geworden.

Ben ik dan ook weer niet met je eens .. nuance nuance ... het is niet zaligmakend .. maar kan je wel helpen bijvb met terugkerende fouten. Maar het schrijven van een echt goede test (die zoals NMe al aangaf ook niet alles zal afvangen) is niet eenvoudig .. je moet eigenlijk je denktrant deels omgooien .. van wat wil ik dat het doet .. naar wat voor factoren wil ik dat het allemaal tegen bestand is. En aangezien je toch altijd begint met "wat wil ik dat het doet" .. is dat lastig.

[ Voor 26% gewijzigd door gekkie op 17-05-2015 17:08 ]

[hydrargyrum]

Oke, dan snap ik nu de functies van unittests en waarom het de shit zou moeten zijn. Heel erg bedankt voor alle inbreng, en ook voor de discussie!