TDD in de praktijk

[Daos]

Naar aanleiding van mijn opmerking in het boekentopic hier een topic over Test Driven Development (TDD) in de praktijk.

Het principe van TDD is dat je de volgende stappen herhalend doet totdat je programma af is:

1. Je schrijft 1 kleine unit-test die faalt
2. Je schrijft code zodat die test en de rest slagen
3. Je maakt de code mooier

Ik heb dit geprobeerd bij een klein project (3kloc) en daar beviel het mij al niet. Bij grotere projecten verwacht ik dat het nog slechter werkt.

Mijn bezwaren zijn:

• Het gaat verschrikkelijk traag. De hele tijd switch je tussen test-code en echte code.
• Stap 3 versloft. Op een gegeven moment ga je echt niet meer steeds je hele code herstructureren. Je krijgt uiteindelijk bagger code. Als je stap 3 wel trouw doet, gaat het nog trager.
• Je vergeet veel te testen (bv boundary cases).

Tegenwoordig ben ik wel fan van unit-tests. (Vroeger had ik een houding van: 1 keertje je code goed doorlezen en het is zo goed als foutloos)

Hoe doe ik het dan wel? (als de werkgever het goed vindt; ik heb bij verschillenden "wij doen niet aan unit-tests" gehoord)

• Je maakt een aantal unit-tests met functionaliteit die je wilt hebben; het liefst een hele klasse in 1 keer.
• Je implementeert die functionaliteit zo mooi mogelijk.
• Je maakt tests voor de boundary cases.

De vraag is nu: werkt TDD voor jou wel in de praktijk? Hoe ga je om met de problemen die ik ervaar? Of ervaar je andere problemen? En als je anders test: hoe test je?

[HMS]

Aangezien ik de poster ben in het boekentopic, zal ik hier ook even reageren .

Het tweede boek op mijn lijst (deze) legt mooi uit hoe TDD in elkaar zit.

Zij stellen dat TDD meer is dan simpel unit tests schrijven, het is een iteratieve ontwikkelmethode op zichzelf. Het concept is dat je door middel van uitvoerbare en herhaalbare tests bepaald vertrouwen krijgt in je code. TDD met alleen unit tests geeft dat niet perse. Daarom moet je TDD ook als een gelaagde set van tests zien.

Zoiets bijvoorbeeld:
Buitenste laag -> Acceptatie tests
Middelste laag -> Integratie tests
Binnenste laag -> Unit tests

Het doel is om de applicatie van voor tot achteren automatisch te kunnen doorlopen. Dus van GUI tot database. Fouten in (bijvoorbeeld) je unit tests, zouden afgevangen moeten worden door je integratie tests (of als die niet goed zijn, de acceptatie tests).

Het idee is dan ook om niet alleen de code te unit testen, maar om het hele delivery process er ook mij te testen. Dan ga je dus richting (het mogelijk maken van) continuous delivery.

Hiermee haal je de angst en chaos uit je ontwikkelproces. Als een klant vandaag vraagt om morgen een oplevering te doen, dan zou dat geen probleem moeten zijn. Natuurlijk zal bepaalde functionaliteit nog niet af zijn, maar de angst om een oplevering te doen is een stuk kleiner aangezien het uitrollen naar een test of ontwikkelomgeving hetzelfde proces is als het uitrollen naar productie.

Ik moet er nu vandoor, maar ik zal dit topic wel even in de gaten houden. Ik vind het zelf namelijk ook een leuk onderwerp om over te discussiëren.

offtopic:
Disclaimer: Ik moet de boeken nog lezen, maar dit is wat ik zo uit de eerste hoofdstukken heb gehaald. Ik zal hier en daar nog wel iets over het hoofd gezien hebben / fout geïnterpreteerd, maar volgens mij is dit in grote lijnen het concept TDD

[EddoH]

Ik vind de gedachte achter TDD natuurlijk erg mooi, maar toch vraag ik me altijd af of er ook maar 1 commercieel bedrijf is dat volledig volgens de TDD methodologie ontwikkelt. In mijn ervaring gaat de ontwikkeling bij pure TDD veel te traag om in een commerciele setting interessant te zijn. Uiteraard krijg je er als je het goed doet een stabiele codebase van, en zul je zeker tijdswinst boeken bij onder andere onderhoud aangezien er minder bugs in de upgeleverde versies sluipen, maar om alles te testen kost zo ongelovelijk veel tijd, helemaal bij non triviale en vooral asynchrone systemen.

Daarnaast vind ik het unit testem stiekem wel eens heel erg saai woorden: al die tests, mock objects etc etc die je moet gaan maken zijn nou niet echt uitdagend om te implementeren en het risico is dan ook dat je uiteindelijk shortcuts gaat nemen, die leiden tot halfbakken (unit)-tests en een vals gevoel van zekerheid geven.

In de praktijk zorg ik ervoor dat core componenten vergezeld gaan van unit tests, maar deze worden vaak achteraf gemaakt, omdat er nogal eens wat prototyping gedaan wordt, welke daarna opgeschoond wordt naar de uiteindelijk versie van de code. Voor de overige 60% van de code worden er uberhaupt geen testen gemaakt of gedaan.

Er zullen nu vast heel wat reacties komen met de stelling dat als unit-testen van je code te veel tijd kost en te weinig oplevert, je het verkeerd doet
Toen ik nog in een team zat waar de ontwikkeling van 1 core component de hoofdmoot was zou ik het daar mee eens mee zijn geweest: je kunt vaak test mechanismen herbruiken en 1 test 'technologie' voor het grootste deel van je code gebruiken. Nu ik dagelijks met meerdere talen en projecten bezig ben, waarbij ieder project vaak niets tot weinig deelt met andere projecten kost het testen van alles gewoon teveel tijd: grotendeels door de initele start-up tijd die het maken van tests voor een bepaald framework/ taal met zich meebrengt.

[Caelorum]

EddoH schreef op zondag 05 januari 2014 @ 12:17:
[...]. Uiteraard krijg je er als je het goed doet een stabiele codebase van, en zul je zeker tijdswinst boeken bij onder andere onderhoud aangezien er minder bugs in de upgeleverde versies sluipen, maar om alles te testen kost zo ongelovelijk veel tijd, helemaal bij non triviale en vooral asynchrone systemen. [...]

Ik denk dat het daar ook gewoon in zit. Als je weet dat de software de komende 20 jaar nog moet worden onderhouden inclusief alle aanpassingen enz. dan lijkt het me handig om maar die extra initiële ontwikkeltijd te incasseren. Bijv. als je een OS moet gaan bouwen of andere kritieke software.
Ik denk dat voor de meeste software de afweging extra initiële ontwikkelkosten (wel TDD) vs. hogere onderhoudskosten (niet TDD) best wel eens richting niet TDD kan vallen. Al blijft het uiteindelijk altijd wel gokken en denk ik dat veel bedrijven ook liever in hun comfortzone blijven.

[Megamind]

Caelorum schreef op zondag 05 januari 2014 @ 17:10:
[...]

Ik denk dat het daar ook gewoon in zit. Als je weet dat de software de komende 20 jaar nog moet worden onderhouden inclusief alle aanpassingen enz. dan lijkt het me handig om maar die extra initiële ontwikkeltijd te incasseren. Bijv. als je een OS moet gaan bouwen of andere kritieke software.
Ik denk dat voor de meeste software de afweging extra initiële ontwikkelkosten (wel TDD) vs. hogere onderhoudskosten (niet TDD) best wel eens richting niet TDD kan vallen. Al blijft het uiteindelijk altijd wel gokken en denk ik dat veel bedrijven ook liever in hun comfortzone blijven.

Het is lastig om hier een berekening op los te laten aangezien je dan eigenlijk 2x hetzelfde project zou moeten doen: 1x met TDD en 1x met tests achteraf.

Ik forceer wel TDD bij mijn mensen omdat in mijn ervaring is gebleken dat een test achteraf schrijven vaak geen goede test is. De test wordt dan geschreven op de code die al getikt is, een test vooraf wordt geschreven naar de specificatie. Ik heb gemerkt dat een aantal tests die achteraf geschreven zijn niet volgens de specs waren omdat het stuk code überhaupt niet goed was.

Wat we ook wel doen is dat de seniors tests schrijven met falende code die wel compileerd waarna een junior aan de slag gaat met de code waarna weer een code-review plaatstvindt.

Er wordt uiteraard wel geklaagd dat het veel tijd kost elke keer weer tests te schrijven maar achteraf is er weer verlichting door het hele team omdat de code-coverage altijd netjes hoog blijft.

Ik heb het hier wel over een product waar constant aan ontwikkeld wordt, niet een eenmalig project.

[Precision]

Wij hebben op het werk geëxperimenteerd met het volgende:
1 persoon schrijft eerst de tests dan schrijft iemand anders de code. Dit zorgt ervoor dat de test persoon goed moet nadenken over zijn tests. Als je zo eens gewerkt hebt ga je beter en verder nadenken voor je vervolgens een letter typt. Natuurlijk was dit een experiment en doen we dit niet meer, maar je leert er wel van.

[Grompie]

Het grote voordeel aan TDD is natuurlijk bij grote projecten voelbaar wanneer er bij later veranderingen plots een test faalt en er zo sneller bugs kunnen opgespoord worden. Dit is natuurlijk ook van toepassing bij kleinere projecten maar hier moet je je afvragen of het de tijd waard is.

De testen zelf schrijven vind ik het moeilijkste omdat je soms niet altijd weet wat je wilt testen, ook voor mensen die nieuw zijn in unit tests is de instap drempel nogal hoog vind ik.

[webboef]

Voor mij was (en is) het vooral een kwestie van oefenen. In het begin vond ik het tijdverspilling, nu weet ik bij grotere projecten dat het me uiteindelijk tijd gaat opleveren. Wat vooral heeft geholpen is Dependency Injection, om code beter te testen (zoek eens op SOLID) en daarbij TDD kata's te doen (via google ook zat te vinden) om te blijven oefenen.

Als je eenmaal wat handigheid hebt, zul je zien dat je je software-ontwerp ook een stuk beter maakt.

[pderaaij]

TDD is absoluut de moeite waard! Zelf geloof ik alleen niet altijd in het strakke mantra van eerst de test schrijven. Soms heb je simpelweg nog geen volledig beeld hoe je het zaken gaat implementeren. Ik geloof dan ook meer in DIRTI zoals beschreven in deze blog post:

http://blog.ircmaxell.com/2013/11/beyond-clean-code.html

[kenneth]

Dat DIRTI klinkt heel erg zoals Kent Beck TDD heeft bedoeld. Wat is nu het verschil? Vergeleken met Red/Green/Refactor is Green de D, Refactor de IRT. De laatste I komt er dan bij maar integreren moet je sowieso.

edit:

Beter gelezen, de hele test vooraf vervalt. Maar hoe weet je dan wanneer je klaar bent met code schrijven? Hoe weet je dat je geen andere functionaliteit breekt? Hoe kan je wél weten wat je moet programmeren maar niet een test schrijven die die code zou gebruiken?

[ Voor 37% gewijzigd door kenneth op 06-01-2014 14:24 ]

[Megamind]

Grompie schreef op maandag 06 januari 2014 @ 09:21:

De testen zelf schrijven vind ik het moeilijkste omdat je soms niet altijd weet wat je wilt testen, ook voor mensen die nieuw zijn in unit tests is de instap drempel nogal hoog vind ik.

Dat is juist de perfecte controle om te zien of je wel goed over je specs hebt nagedacht.

[pderaaij]

kenneth schreef op maandag 06 januari 2014 @ 14:22:
Dat DIRTI klinkt heel erg zoals Kent Beck TDD heeft bedoeld. Wat is nu het verschil? Vergeleken met Red/Green/Refactor is Green de D, Refactor de IRT. De laatste I komt er dan bij maar integreren moet je sowieso.

TDD gaat er vanuit dat je de specs al duidelijk hebt als je gaat ontwikkelen. Vaak is dit goed en gewenst, maar soms ook niet mogelijk. Integraties met andere systemen bijvoorbeeld of een probleemstelling in een nieuw domein.

Als je dan DIRTI volgt begin je eerst met de ontwikkeling. Isoleer je de abstracties en overige refactorings en dan volgt het schrijven van je testen voor de waarborging.

Het zit heel dicht bij elkaar

[Janoz]

Maar even mijn duit in het zakje

Daos schreef op zaterdag 04 januari 2014 @ 17:33:
Het principe van TDD is dat je de volgende stappen herhalend doet totdat je programma af is:
[list=1]
• Je schrijft 1 kleine unit-test die faalt

Hier ga je imho eigenlijk al de fout in. Niet omdat de actie niet klopt, maar omdat je hem eigenlijk verkeerd omschrijft. Dichter bij de waarheid is "Je schrijft een unittest met de gewenste functionaliteit welke zeer waarschijnlijk gaat falen"

• Je schrijft code zodat die test en de rest slagen

Waarbij deze vervolgens veranderd in "Je implementeerd de benodigde functionaliteit zodat de tests slagen"

• Je maakt de code mooier

En dan nu je bezwaren

Mijn bezwaren zijn:
• Het gaat verschrikkelijk traag. De hele tijd switch je tussen test-code en echte code.

Die begrijp ik niet helemaal. Mijn gewone en test code staat in dezelfde workspace en me de debugger step ik zo van de testcode de werkelijke code in. Sterker nog. Het werkt in mijn opinie juist een stuk sneller, maar daar kom ik zo op terug.

• Stap 3 versloft. Op een gegeven moment ga je echt niet meer steeds je hele code herstructureren. Je krijgt uiteindelijk bagger code. Als je stap 3 wel trouw doet, gaat het nog trager.

Als ik mijn code herstructureer wordt deze over het algemeen beter, en als dat niet zo is zorgt een revert ervoor dat ik weer terug ga naar de variant die toch beter leek. Daarnaast kost het 'netter' maken eigenlijk helemaal geen tijd mits je goede tooling gebruikt. Met een paar sneltoetsen creeer ik locale variabelen waar nodig, extract of inline ik methods of pull ik functionaliteit up. Met goede tooling, goede testcoverage en de backup van het VCS heb ik ook het lef en vertrouw om de boel ff flink om te gooien.

• Je vergeet veel te testen (bv boundary cases).

Tja, juist de boundary cases is waar ik zelf mee begin aangezien. Die zij juist vaak het makkelijkste .


Voor al die mensen die unittests schrijven lang vinden duren: Hoe controleer je je geschreven code?

Uiteraard weet ik dat zelf ook wel, maar ik stel de vraag voornamelijk om jullie er zelf eens over na te laten denken. Al die tijd die je nu kwijt bent aan het (lokaal) deployen, vervolgens je applicatie opstarten en door de schermen heen klikken tot je bij het stuk bent waar je op dat moment mee bezig bent om vervolgens te kijken of de query die je net geschreven hebt de juiste resultaten oplevert. Of dat formuliertje invullen, op opslaan drukken en vervolgens terug gaan naar het overzichtsscherm om te zien dat het itempje ook volledig doorgekomen is. Dat kost ook allemaal tijd. Zeker wanneer je fix net niet helemaal goed is kan het best zijn dat je die cyclus meerdere keren moet doorlopen. En vervolgens moet je ook nog even handmatig naar de rest kijken of daar alles nog goed gaat. Ongezien gaat daar ook behoorlijk wat tijd in zitten. Tijd die je je kunt besparen door veel van dit werk met geautomatiseerde tests af te dekken.


Uiteraar dmoet ik bekennen dat ik ook niet volledig TDD werk. Zeker omdat ik vaak aan de volgende YADFE werk en een service methode vaak niet meer is dan dezelfde methode in de dao aanroepen. Met een beetje fatsoenlijke integratie test heb ik dan de hele keten wel afgedekt. Wat echter fantastisch TDD werkt is bugfixing. Zodra er een bevinding binnenkomt van de testers is het altijd heel fijn om een unit of integratie test te schrijven welke precies die bug triggert.

Ten eerste zorgt het omzetten van de omschrijving van de bug naar de unittest alvast voor een stukje begrip van die bug. Het daadwerkelijk fixen wordt ook een stuk simpeler. Het starten van de debugsessie vind ik vanuit een unittest veel makkelijker dan vanuit een live draaiende omgeving.

Het bouwen van de unittest kost eigenlijk nauwelijks extra werk. De uitgangssituatie en de verwachte uitkomst heb je toch al nodig (ook als je telkens weer handmatig kijkt of de bug gefixed is), alleen beschrijf je die nu in de test.

[storeman]

Ik ben met een nieuw project ook aan proberen de TTD weg in te slaan. Ik had echter al een codebase gemaakt, dus testdriven is het (nog) niet, maar ik merk wel dat ik veel objectiever en functioneler naar code kijk. Meer delegeren, opsplitsen en compactere functies. Bovendien vind ik het een stuk vlotter testen dan allerlei schermen doorklikken, zoals Janoz ook terecht opmerkt.

Het blijft natuurlijk wel zo dat de front-end (in mijn geval HTML/JS) ver af staat van de te testen code (PHP). Front-end testing heb ik tot nu toe nooit fantastisch gevonden. Want hoe test je of een pagina goed wordt weergegeven? Ik zou zelf niet twee html-string willen vergelijken. Als je een form rendert en in je rendering class een aanpassing maakt, dan moet je wel heel veel pagina's door.

Overigens probeer ik dit ook goeddeels af te vangen door het renderen zelf te testen. Hoe dit dan precies op een pagina staat, zal wel voldoende goed gaan.

[creator1988]

TDD kan volgens mij alleen als je super duidelijke en hele kleine units of work hebt. Een OS zal je niet TDD gaan schrijven (zoals dat hierboven genoemd werd). Maar ik heb vorige week code voor clipboard handling geschreven, ja dan gooi je een test neer en dan schrijf je daarna de implementatie. Daar is de spec heel erg duidelijk (maar je moet wel weer je IDL eerst schrijven, dus helemaal TDD is het nou ook weer niet) en heel klein.

Maar 98% van de code die je schrijft past hier helemaal niet in. Zeker als je nieuwe functionaliteit schrijft, ben je constant aan het itereren qua functionaliteit, code door elkaar gooien, event patterns veranderen. Dus daarom schrijf ik mijn tests (integratie en unit) nadat ik klaar ben.

[Janoz]

Sorry, maar dat zie ik niet. Waarom zou je niet een unittest kunnen schrijven voor het resolven van een symbolic link naar de juiste inode?

[creator1988]

Janoz schreef op maandag 06 januari 2014 @ 16:43:
Sorry, maar dat zie ik niet. Waarom zou je niet een unittest kunnen schrijven voor het resolven van een symbolic link naar de juiste inode?

Ja, maar dan heb je weer een heel specifiek en heel kleine unit of work. En dan nog, het gaat hier over TDD, dus schrijf je die test vooraf of achteraf. Als jij een nieuw concept met symbolic links hebt, dan ga je daar eerst wel mee klooien en een testimplementatie schrijven om te zien of het uberhaupt kan gaan werken, dan eerst een mooie TDD implementatie maken.

[ Voor 31% gewijzigd door creator1988 op 06-01-2014 16:53 ]

[Caelorum]

Waarom? Je weet toch welk resultaat je wilt hebben en wat niet dus kan je daar toch tests voor schrijven? Dan kan je daarna wel gaan zitten proberen welke implementatie het beste is, maar weet je in ieder geval zeker dat je het gewenste resultaat krijgt. Ik zie eigenlijk ook niet waarom je niet een OS TDD zou kunnen ontwikkelen. Of je het wil of dat het daadwerkelijk zo gebeurt is een tweede, maar dat staat los van of het niet zou kunnen (of zelfs wenselijk is).

[Gomez12]

creator1988 schreef op maandag 06 januari 2014 @ 16:51:
[...]
Als jij een nieuw concept met symbolic links hebt, dan ga je daar eerst wel mee klooien en een testimplementatie schrijven om te zien of het uberhaupt kan gaan werken, dan eerst een mooie TDD implementatie maken.

Tja, dat is leuk als je wat gaat zitten hobby'en. Echter als je professioneel gaat werken dan heb je bijna altijd (zo niet altijd) al bekend wat er uit moet komen (want dat is namelijk wat de klant wenst).

Oftewel dan heb je een uitkomst en mag je gaan "klooien" om die uitkomst te bereiken ipv maar wat "te klooien" zonder dat je weet waar je eindigt.

[creator1988]

Gomez12 schreef op maandag 06 januari 2014 @ 17:33:
[...]

Tja, dat is leuk als je wat gaat zitten hobby'en. Echter als je professioneel gaat werken dan heb je bijna altijd (zo niet altijd) al bekend wat er uit moet komen (want dat is namelijk wat de klant wenst).

Oftewel dan heb je een uitkomst en mag je gaan "klooien" om die uitkomst te bereiken ipv maar wat "te klooien" zonder dat je weet waar je eindigt.

Voorbeeldje, vandaag ben ik bezig met dynamic hit states op een touch keyboard. Als in: als je 'Hall' hebt getypt is de kans dat je een 'o' bedoeld met een NL locale groter dan een 'p'. Hoe groot die hit states moeten zijn, of en zoja hoe snel ze kleiner moeten worden, hoe de weging van toetsen onderling is en hoe je dit inplugt op je bestaande keyboard zijn dingen die je onderweg uitvind; niet zaken die je vooraf allemaal kan bepalen.

[farlane]

Gomez12 schreef op maandag 06 januari 2014 @ 17:33:
[...]

Tja, dat is leuk als je wat gaat zitten hobby'en. Echter als je professioneel gaat werken dan heb je bijna altijd (zo niet altijd) al bekend wat er uit moet komen (want dat is namelijk wat de klant wenst).

Als de klant weet wat hij wil ja, en bij onze klanten is dit meestal niet het geval maar wordt dat pas tijdens het project helemaal duidelijk.

[Janoz]

@creator1988
Sowieso moet dat opgesplitst worden. Aan de ene kant heb je de functionaliteit die een teken op moet leveren bij een gegeven voorgaande reeks tekens, het ingegeven teken, en de omliggende tekens. Aan de andere kant heb je een stuk configuratie waarin staat welke tekensreeksen vaak voorkomen en waar bepaalde toetsen op het toetsenbord staan en hoe snel de weging moet aflopen obv de afstand tot die toetsen.

De functionaliteit is juist heel goed test driven te implementeren. Ook de randgevallen zijn heel goed te vinden. Gewoon een heel simpele 'locale' met een beperkte dictionary maken en los gaan met iets als

- als er in de omliggende toetsen geen verwacht teken zit dan altijd de ingedrukte nemen
- zijn er twee tekens met dezelfde uiteindelijke kans dan neem je het teken dat je ingetikt hebt
- is de kans op een ander teken hoger dan de drempel dan moet het andere teken eruit komen
enz enz


De configuratie is vervolgens te tweaken bij een gebruiker/acceptatie achtige test. Dat is trouwens ook nog heel goed met unittest te doen. Je hebt immers input, en een verwachting. Ik verwacht dat er, als ik na 'Hall' een 'p' indruk dat er bij een NL locale dan een 'o' uit komt.

het grote probleem wat jij je nu op je hals haalt is dat je eigenlijk een japans scheikunde boek hebt. Als de boel straks even niet zo werkt als jij bedoeld had, dan weet je niet of het komt door een fout in de functionaliteit (je japans), of door een fout in de configuratie (je scheikunde).

@farlane
Ik neem niet aan dat je aan het infinite monkey programming bent. Zodra je aan iets begint weet je toch wat dat stukje iets zou moeten doen. Als je een gesorteerde lijst van items moet hebben dan maakt het natuurlijk geen drol uit hoe het inloggen gaat werken.

[Barbas]

Daos schreef op zaterdag 04 januari 2014 @ 17:33:
• Je vergeet veel te testen (bv boundary cases).

Verzin je zelf je tests? Zo ja, waarom betrek je er dan geen tester bij voor het verzinnen van de scenario´s?

[farlane]

Janoz schreef op dinsdag 07 januari 2014 @ 14:16:
@farlane
Ik neem niet aan dat je aan het infinite monkey programming bent. Zodra je aan iets begint weet je toch wat dat stukje iets zou moeten doen. Als je een gesorteerde lijst van items moet hebben dan maakt het natuurlijk geen drol uit hoe het inloggen gaat werken.

Nee, ik heb het over veranderende requirements, bv door voortschrijdend inzicht van de klant (of iemand anders ).

[Oljoner]

Zelf probeer ik ook zoveel mogelijk TDD te werken.
Dit meestal door eerst een kleine "happy path" test van de interface te schrijven. Hierbij let ik er zoveel mogelijk op om tot een gebruiksvriendelijke api (of samenwerking van api's) te komen. Dit dwingt me om vanuit een vogelperspectief over het probleem na te denken. Deze kleine test kan in het begin verschillende keren grondig veranderen.

Vervolgens begin ik aan de implementatie en voeg ik tests voor corner cases toe wanneer ze in m'n hoofd opkomen (of ik noteer ze even op een noteblok, om ze nadien in code toe te voegen).

Meestal hou ik m'n tests redelijk high level. Enkel wanneer bepaalde methodes ingewikkeld worden, test ik ze apart.
Wanneer ik een bugreport binnenkrijg, maak ik er eerst een test van voordat ik ze fix. (Vroeger, toen ik dat niet deed, durfde het nogal eens voorvallen eenzelfde bug opnieuw in de code sloop door een refactoring. Nogal beschamend zoiets..)
Het resultaat is dat ik nu veel meer vertrouwen heb in m'n code. Vroeger was ik heel terughoudend om grote aanpassingen in m'n code te doen. Nu schrik ik er niet voor terug en ga ik er van uit dat code die door m'n testen geraakt en toch een bug blijkt te bevatten eigenlijk al lang een bug was.. die nu pas bovenkwam. Deze bug zal dan niet meer voorkomen aangezien ik er onmiddelijk een test voor schrijf.

Wat ik wel een serieuze pita vind, is het testen van database toegang met bijvoorbeeld dbUnit. Dit werkt enorm omslachtig en tijdrovend. Dit vermijd ik dan ook zoveel mogelijk door meer met mocking te werken. Maar het blijft voorlopig een klein gapend gat in m'n testcode ...


Wat me wel opvalt bij collega's, is dat velen onder hun propere code proberen te schrijven. Maar hun testen? Ho maar! Wat een warboel. Vaak testen ze 1 methode in 1 enkele unit test. Persoonlijk zie ik liever leesbare testcode gecombineerd met half onleesbare code dan omgekeerd .

Zelf volg ik de naming convention van Roy Oshorove (zie volgende guideline: http://osherove.com/blog/...dards-for-unit-tests.html) (nog een interessante video: YouTube: Understanding Test Driven Development ). Hierdoor blijven mijn testmethodes zeer klein, testen ze 1 specifieke case en kunnen ze gemeenschappelijke initialisatie van objecten groeperen.

[Gomez12]

farlane schreef op dinsdag 07 januari 2014 @ 16:56:
[...]

Nee, ik heb het over veranderende requirements, bv door voortschrijdend inzicht van de klant (of iemand anders ).

In theorie is dit geen probleem voor TDD. Je schrijft gewoon tests voor wat wel definitief is en daarna pas code voor die tests. Veranderen daarna de requirements dan pas je eerst je tests aan en daarna pas de code.

Maar zoals ik al zeg, dat is in de theorie, in de praktijk is dit ook 1 van de belangrijkste redenen waarom wij geen TDD gebruiken : De klant wenst geen oneindige tests te gaan betalen.
TDD is (imho) heel schitterend voor een 110% uitgekristalliseerd eisenpakket want dan kan het de onderhoudskosten omlaag brengen, maar in een situatie met een wispelturige klant (of simpelweg een brakke projectleider die niet de wensen van de klant kan vertalen zoals de klant het bedoelt heeft) betekent TDD al snel >2x kosten omdat er allemaal tests voor jan met de korte achternaam geschreven moeten worden.

[Barbas]

Het maakt in dat geval dan toch helemaal niks uit welke methode je hanteert? Als de wensen van de klant niet goed vertaald worden dan blijf je toch ook onnodig code schrijven? Dus het probleem van "slechte requirements" dus dan maar geen TDD gaat in mijn ogen niet op, dan moet er "maar" gezorgd worden voor heldere en scherp geformuleerde requirements. (makkelijker gezegd dan gedaan )

[HMS]

Als requirements veranderen dan ben je sowieso de pineut, want dan moet je je code alsnog om- of weggooien. Dat de klant akkoord gaat met iets betekend ook dat er voor betaald moet worden, wil hij het toch anders dan gaat de meter gewoon weer lopen.

Ik snap niet hoe het wel of niet hebben van TDD dit anders maakt.

Om het even om te draaien, als de klant zijn mening niet veranderd. Wanneer ga je dan de unit tests schrijven? Of doe je dan maar geen unit tests? Stel 1 week voor de deadline veranderd de klant van gedachten? Heb je dan al unit tests, of schrijf je die na de oplevering? Hoe weet je dan of wat je test juist is?

Het risico met achteraf testen is dat je test naar wat je weet dat de code doet, niet naar wat jij verwacht wat het zou moeten doen.

[Janoz]

farlane schreef op dinsdag 07 januari 2014 @ 16:56:
[...]

Nee, ik heb het over veranderende requirements, bv door voortschrijdend inzicht van de klant (of iemand anders ).

Ja, maar dat heeft helemaal niks met het kleine stukje unit of work te maken welke je test driven op kunt pakken. TDD betekent niet dat je eerst al je tests voor de hele applicatie schrijft. TDD betekent dat je, bij het oppakken van je kleine taakje, de functionele eisen van dat kleine stukje eerst in een test giet, en dan pas de bijbehorende code schrijft. Zo'n taak zou niet meer dan een halve dag tot 2 dagen mogen duren, en als dat wel zo is dan moet je die taak verder opdelen. En als je op zo'n kleine taak van een halve dag al meerdere keren door de klant gestoord wordt dat dat stukje weer helemaal anders moet dan heb je een veel groter probleem.

[Barbas]

HMS schreef op dinsdag 07 januari 2014 @ 20:02:
Het risico met achteraf testen is dat je test naar wat je weet dat de code doet, niet naar wat jij verwacht wat het zou moeten doen.

En dit punt is waar het juist waar het om gaat!

[Oljoner]

Gomez12 schreef op dinsdag 07 januari 2014 @ 19:40:
[...]

Maar zoals ik al zeg, dat is in de theorie, in de praktijk is dit ook 1 van de belangrijkste redenen waarom wij geen TDD gebruiken : De klant wenst geen oneindige tests te gaan betalen.

Zoals Janoz al zei: wat kost het meeste tijd: 1)deployen en al klikkend alles afchecken of 2) een test schrijven en die groen krijgen?

Het deployen en klikken is wel leuk, je ziet namelijk direct resultaat van wat je aan het maken bent. Maar tenzij je er bij iedere release weer door gaat klikken wordt het al snel een blinde vlek.

Imo betaalt de klant niet enkel voor software die werkt, maar voor software die blijft werken bij iedere update. Als de tijd echt dringt zou ik enkel high level testen, dbunit enz zou ik dan ook laten voor wat het is, maar het blijft een berekend risico.

[Oljoner]

HMS schreef op dinsdag 07 januari 2014 @ 20:02:
...

Volledig mee akkoord. Bijkomend: als het gaat om snel veranderende requirements gaat het imo al zeer snel voor 90% over de gui. Van deze testen (vb selenium) is het een gegeven dat ze zeer vluchtig zijn, maar ik ga ervan uit dat deze niet de hoofdmoot van het programma uitmaken?

[Barbas]

Ik ben verder van mening dat hoe eerder zaken te testen zijn, hoe beter. De tijd die men in het begin kwijt zal zijn met het schrijven van de tests wordt later in het project teruggewonnen, doordat de kwaliteit een stuk hoger zal liggen.

[HMS]

Selenium tests gebruik ik zelf niet, maar ik kan me wel voorstellen dat die erg 'brittle' zijn en dus vaak stuk zullen gaan door ongerelateerde changes. Je moet je dan even afvragen of het wel zo'n goed idee is om ze te hebben, aangezien ze hun doel niet kunnen waarmaken (ze zijn niet betrouwbaar, dus zul je ze eerder negeren. Of ze vragen erg veel onderhoud.).

Het liefst breng ik ook een applicatie helemaal onder geautomatiseerde tests, het liefst integratie tests die van UI tot DB werken. Maar dit is wel erg veel werk, dus hier moet je een afweging gaan maken.

[farlane]

Janoz schreef op dinsdag 07 januari 2014 @ 20:06:
[...]

Ja, maar dat heeft helemaal niks met het kleine stukje unit of work te maken welke je test driven op kunt pakken. TDD betekent niet dat je eerst al je tests voor de hele applicatie schrijft. TDD betekent dat je, bij het oppakken van je kleine taakje, de functionele eisen van dat kleine stukje eerst in een test giet, en dan pas de bijbehorende code schrijft. Zo'n taak zou niet meer dan een halve dag tot 2 dagen mogen duren, en als dat wel zo is dan moet je die taak verder opdelen. En als je op zo'n kleine taak van een halve dag al meerdere keren door de klant gestoord wordt dat dat stukje weer helemaal anders moet dan heb je een veel groter probleem.

Dat klopt, mijn kritiek was dan ook niet op TDD want ik zie daar weldegelijk waarde in maar op de gechargeerd uitspraak van Gomez die beweert:

Tja, dat is leuk als je wat gaat zitten hobby'en. Echter als je professioneel gaat werken dan heb je bijna altijd (zo niet altijd) al bekend wat er uit moet komen (want dat is namelijk wat de klant wenst)."

Als TDD kan toevoegen aan het gemak waarmee op veranderende requirements kan worden ingespeeld (of het in ieder geval niet lastiger maakt ) dan zou het [voor ons] zeker een kans kunnen maken. Alleen al het nadenken over de test is eigenlijk nadenken over (het design van) je software ( die je dus nog moet gaan maken )

[pedorus]

Resteleiro schreef op dinsdag 07 januari 2014 @ 20:18:
De tijd die men in het begin kwijt zal zijn met het schrijven van de tests wordt later in het project teruggewonnen, doordat de kwaliteit een stuk hoger zal liggen.

Heb je hier ook een onderbouwing voor, of is dit een mening?

Ik quote mezelf:

pedorus schreef op donderdag 17 oktober 2013 @ 00:19:
Het probleem van TDD is dat het enige aantoonbare verschil de grotere initiële developmenttijd is, voor kwaliteit daarna is de situatie wellicht een beetje positief, en voor productiviteit is de situatie onbekend. De adoptie valt (daarom?) ook tegen. Bronnen: mijn ervaring, deze review uit 2010, en ik zie nu een nieuwe uit 2013, maar de situatie is niet veranderd: http://doi.ieeecomputersociety.org/10.1109/TSE.2012.28

Janoz schreef op maandag 06 januari 2014 @ 15:28:
Voor al die mensen die unittests schrijven lang vinden duren: Hoe controleer je je geschreven code?

Nog voor we bij controleren zijn, hebben we het allerbelangrijkste vergeten: Tijd is kostbaar. Deze moet goed geïnvesteerd worden: eerst goed nadenken wat je wil maken, en hoe dit gaat werken. Geen tijd verspillen aan onzin, bijvoorbeeld een oplossing die niet alle gevallen zal kunnen afvangen. Een test schrijven voor een methode die nooit succesvol gebouwd kan worden, dat soort dingen. Een goed programmeerconcept hebben voordat je begint met uitwerken, is het allerbelangrijkste.

Vervolgens het testen: Door het te draaien en te kijken of het werkt. Eventueel breakpoints te zetten en te kijken of het gaat zoals je conceptueel dacht. Een voorbeeld: Zojuist iets geschreven om bij plaatjes de aspect ratio terug te geven, en aan de hand daarvan goed weer te geven in vakjes. De klasse om de dimensies van plaatjes op te vragen (zonder daadwerkelijk inladen) natuurlijk niet zelf verzonnen, maar bestaande code voor gepakt. Eigenlijk zat daar de core logic, dus verder is er geen unit test nodig volgens mij, dus gewoon direct uitgeprogrammeert en getest in een browser. Wat denk je? Het werkte direct. Voor sommige organisaties zou ik hier een unit test voor hebben moeten schrijven, ivm code coverage, eigenlijk verspilde tijd. Voor je het weet denk je dat het werkt omdat je unit tests slagen en je alle/veel code covert, maar klopt de functionaliteit niet.

Overigens "vind" ik het niet alleen lang duren, uit urendeclaraties blijkt dit ook...

Resteleiro schreef op dinsdag 07 januari 2014 @ 19:52:
Het maakt in dat geval dan toch helemaal niks uit welke methode je hanteert? Als de wensen van de klant niet goed vertaald worden dan blijf je toch ook onnodig code schrijven? Dus het probleem van "slechte requirements" dus dan maar geen TDD gaat in mijn ogen niet op, dan moet er "maar" gezorgd worden voor heldere en scherp geformuleerde requirements. (makkelijker gezegd dan gedaan )

Dit hoeft niks met "slechte requirements" te maken te hebben. Ik werk ook aan software die problemen oplost die waarschijnlijk niemand anders ooit eerder heeft opgelost, en waarvan niet eens bekend is of het überhaupt kan. Het is dan ook niet mogelijk om met zekerheid van te voren te weten wat goed gaat werken.

In veel gevallen, bij grote bank/verzekeraar/vervoersmaatschappij/enz X met standaardsituatie Y, ligt dit natuurlijk anders.

Janoz schreef op dinsdag 07 januari 2014 @ 20:06:
TDD betekent dat je, bij het oppakken van je kleine taakje, de functionele eisen van dat kleine stukje eerst in een test giet, en dan pas de bijbehorende code schrijft.

Het schrijven van die test, met eventuele mock/test objects e.d. die meestal nodig zijn, kost tijd. Deze tijd win je niet terug in de toekomst als vervolgens het hele concept niet blijkt te werken en de requirements veranderen.

[Caelorum]

pedorus schreef op woensdag 08 januari 2014 @ 01:13:
[...] Ik werk ook aan software die problemen oplost die waarschijnlijk niemand anders ooit eerder heeft opgelost, en waarvan niet eens bekend is of het überhaupt kan. Het is dan ook niet mogelijk om met zekerheid van te voren te weten wat goed gaat werken.[...]

Dit staat natuurlijk wel compleet los van of je wel of niet TDD kan gebruiken. Ook in situaties waarvan je van te voren niet met zekerheid kan zeggen wat goed gaat werken weet je al wel het gewenste eindresultaat. Hell, ik denk zelfs dat je niet eens een probleem kan oplossen zonder een gewenst resultaat voor ogen te hebben en dat gewenste resultaat kan je natuurlijk ook prima in tests samenvatten. Overigens heeft dat IMO wel met requirements te maken. Die beschrijven namelijk ook het gewenste eindresultaat. Geen goede requirements betekent geen goed beeld van het probleem en het gewenste eindresultaat hebben en dan kan je beter nog helemaal niet beginnen met software oplossingen maar kan je je tijd beter besteden aan het begrijpen van het probleem en wat je nu probeert op te lossen.

[Nick_S]

Er zijn gelukkig meerdere studies geweest over het effect van TDD.

Based on the results, prominent effects include the reduction of defects and
the increased maintainability of code. The internal quality of code in terms of
coupling and cohesion seem not to be affected so much but code complexity might
be reduced a little with test-driven development. With all the tests written, the
whole code base becomes larger but more source code lines are being covered by
tests. Test code is faster to write than the code implementing the test but many
of the studies report increased effort in development.

Uit de studie: Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies.

[Scott]

Caelorum schreef op woensdag 08 januari 2014 @ 01:45:
[...]

Dit staat natuurlijk wel compleet los van of je wel of niet TDD kan gebruiken. Ook in situaties waarvan je van te voren niet met zekerheid kan zeggen wat goed gaat werken weet je al wel het gewenste eindresultaat. Hell, ik denk zelfs dat je niet eens een probleem kan oplossen zonder een gewenst resultaat voor ogen te hebben en dat gewenste resultaat kan je natuurlijk ook prima in tests samenvatten. Overigens heeft dat IMO wel met requirements te maken. Die beschrijven namelijk ook het gewenste eindresultaat. Geen goede requirements betekent geen goed beeld van het probleem en het gewenste eindresultaat hebben en dan kan je beter nog helemaal niet beginnen met software oplossingen maar kan je je tijd beter besteden aan het begrijpen van het probleem en wat je nu probeert op te lossen.

Je weet vaak wel wat het eindresultaat moet zijn, maar niet goed wat de beste manier is om dat te implementeren. Dat kun je dan wel tot in de kleinste details gaan plannen, maar dat werkt niet altijd. Soms moet je gewoon het een en ander proberen. Als je het eerst gaat plannen en je tests schrijven, om tijdens het implementeren erachter te komen dat je het anders aan moet pakken, dan heb je dus je tests voor niks geschreven en is die tijd verloren. (Ik begin sowieso meestal maar gewoon te programmeren in plaats van te plannen wat voor klassen met wat voor functionaliteit ik nodig ga hebben, maar dat zal vast een zwaktepunt van mij zijn .)

Overigens moet ik zeggen dat ik pas recentelijk TDD heb ontdekt en nog niet de gelegenheid heb gehad om er ook wat mee te doen. Hoewel ik absoluut de potentie er van inzie, had ik eigenlijk dezelfde vragen als TS met betrekking tot hoe bepaalde dingen in de praktijk in z'n werk gaan, dus ik volg dit topic met grote interesse!

[Caelorum]

Nee, dat begrijp ik, maar in zo'n geval kan je al wel wat tests schrijven die zo specifiek mogelijk zijn. Dan kan je gaandeweg wel die andere tests schrijven. Het is dan wel niet helemaal zoals 'het hoort', maar wellicht altijd nog beter dan niet tests schrijven voordat je begint.

[Megamind]

Precies, vaak kan je toch iets "werkend" maken met een aantal tests ipv een hele data of businesslaag te hoeven schrijven om het te laten compilen. Ik ken zat mensen die gelijk beginnen met het datamodel waarna en tig iteraties op volgen omdat het toch niet lekker zit.

In alle gevallen kan je je software opdelen in aparte taken die je weer apart kan testen.

[Barbas]

pedorus schreef op woensdag 08 januari 2014 @ 01:13:
[...]

Heb je hier ook een onderbouwing voor, of is dit een mening?

Het is inderdaad een mening Maar ik denk dat tijdens de testfase, wanneer er voor een stukje code een goede test vooraf is opgezet en je weet wat het stukje software moet doen, minder bevindingen zullen zijn doordat de testeffort voor een gedeelte al plaats heeft gevonden. Als er vooraf geen tests zijn dan komt men er op z'n vroegst tijdens de testfase achter. En daarbij. hoe eerder een bevinding gevonden wordt hoe goedkoper het op te lossen is (kromme van Boehm).

[Verwijderd]

Bij iOS-projecten pas ik tegenwoordig ook TDD toe. Als je workflow er op ingesteld is, is het niet eens veel slomer. In Xcode heb ik de test naast de normale code staan, dat zorgt ervoor dat ik enkel naar het andere deel van m'n venster hoef te "switchen".

Een groot voordeel ervan vind ik, dat je vooraf nadenkt over hoe een bepaald deel van je code moet werken. Daarbij moet je ook nadenken over hoe je alles unit-testbaar maakt, dit zorgt in mijn ervaring vaak al voor betere code. Omdat je classes los te testen moeten zijn, zijn ze vaak automatisch niet/minder coupled met de rest van je applicatie.

Maar dat is nog niet eens het grootste voordeel. Door de TS werd aangehaald dat je code een rotzooi wordt. Het mooie is dat daar het grootste voordeel ligt. Als je code een rotzooi wordt, kan je het zo omgooien zonder dat je bang hoeft te zijn dat je bugs introduceert, want dan gaat er een test falen.

Ik prefereer kwaliteit, daarom zal ik altijd voor de TDD-weg gaan waar mogelijk. Het is niet dat de niet TDD-weg (veel) goedkoper is, dan reserveer ik namelijk meer budget voor testen en bugfixes.

[kenneth]

Oljoner schreef op dinsdag 07 januari 2014 @ 18:49:
(nog een interessante video: YouTube: Understanding Test Driven Development ).

Als ik zijn boek heb gelezen, leer ik dan nog iets nieuws van deze video?

[Janoz]

pedorus schreef op woensdag 08 januari 2014 @ 01:13:
Nog voor we bij controleren zijn, hebben we het allerbelangrijkste vergeten: Tijd is kostbaar. Deze moet goed geïnvesteerd worden: eerst goed nadenken wat je wil maken, en hoe dit gaat werken. Geen tijd verspillen aan onzin, bijvoorbeeld een oplossing die niet alle gevallen zal kunnen afvangen. Een test schrijven voor een methode die nooit succesvol gebouwd kan worden, dat soort dingen. Een goed programmeerconcept hebben voordat je begint met uitwerken, is het allerbelangrijkste.

Vervolgens het testen: Door het te draaien en te kijken of het werkt. Eventueel breakpoints te zetten en te kijken of het gaat zoals je conceptueel dacht.

Als je dat nou eens zou kunnen doen, zonder dat je helemaal in de browser rond moet klikken.

Een voorbeeld: Zojuist iets geschreven om bij plaatjes de aspect ratio terug te geven, en aan de hand daarvan goed weer te geven in vakjes. De klasse om de dimensies van plaatjes op te vragen (zonder daadwerkelijk inladen) natuurlijk niet zelf verzonnen, maar bestaande code voor gepakt. Eigenlijk zat daar de core logic, dus verder is er geen unit test nodig volgens mij, dus gewoon direct uitgeprogrammeert en getest in een browser. Wat denk je? Het werkte direct. Voor sommige organisaties zou ik hier een unit test voor hebben moeten schrijven, ivm code coverage, eigenlijk verspilde tijd. Voor je het weet denk je dat het werkt omdat je unit tests slagen en je alle/veel code covert, maar klopt de functionaliteit niet.

Lijkt me nogal een slecht voorbeeld. Dat een resultaat van een service methode op het scherm komt is redelijk triviaal. Echter dat andere stukje code, waar je terecht bestaande en te vertrouwen code/lib voor gebruikt. Stel dat je dat wel zelf had moeten implementeren. Dat lijkt me nu juist wel typisch iets wat je TD kunt doen. Lijstje plaatjes waarvan de de aspect ratio weet in een testje gieten en aan de methode aanbieden. Kun je gewoon die methode implementeren en een paar keer op run drukken zonder dat je een hele gui moet optuigen om het ding aan te roepen.

Dit hoeft niks met "slechte requirements" te maken te hebben. Ik werk ook aan software die problemen oplost die waarschijnlijk niemand anders ooit eerder heeft opgelost, en waarvan niet eens bekend is of het überhaupt kan. Het is dan ook niet mogelijk om met zekerheid van te voren te weten wat goed gaat werken.

In veel gevallen, bij grote bank/verzekeraar/vervoersmaatschappij/enz X met standaardsituatie Y, ligt dit natuurlijk anders.

Juist bij die grote mainframe software heb je voornamelijk met die YADFE te maken waarbij je eigenlijk alleen maar wat data door allemaal tiers trekt zonder dat er werkelijk wat echte functionaliteit geimplementeerd wordt. Je kunt de transformers goed testen die het model in de ene laag omzet naar het model in de volgende laag, maar daarna houd het al snel op.

Juist wanneer je met dergelijke interessante software als die van jou bezig gaat wordt het leuk. Je gaat mij echt niet wijsmaken dat jij een stukje code gaat schrijven zonder dat je weet wat het überhaupt moet gaan doen (dus nog los van hoe). Als ik meer dan 10 jaar terug ook meer aan TDD had gedaan dan had ik waarschijnlijk minder lang lopen kloten met bijvoorbeeld al die kleine off by 1 foutjes in mijn applicatie welke bloedvatstructuren uit een 256^3 bytearray aan MRI data had moeten filteren.

Het schrijven van die test, met eventuele mock/test objects e.d. die meestal nodig zijn, kost tijd. Deze tijd win je niet terug in de toekomst als vervolgens het hele concept niet blijkt te werken en de requirements veranderen.

Of je nu automatisch of handmatig test, je zult altijd test data nodig hebben. Daarnaast is er genoeg tooling beschikbaar om het hele mock gebeuren uit handen te geven.

Scott schreef op woensdag 08 januari 2014 @ 03:13:
[...]

Je weet vaak wel wat het eindresultaat moet zijn, maar niet goed wat de beste manier is om dat te implementeren. Dat kun je dan wel tot in de kleinste details gaan plannen, maar dat werkt niet altijd. Soms moet je gewoon het een en ander proberen. Als je het eerst gaat plannen en je tests schrijven, om tijdens het implementeren erachter te komen dat je het anders aan moet pakken, dan heb je dus je tests voor niks geschreven en is die tijd verloren. (Ik begin sowieso meestal maar gewoon te programmeren in plaats van te plannen wat voor klassen met wat voor functionaliteit ik nodig ga hebben, maar dat zal vast een zwaktepunt van mij zijn .)

Een test zegt helemaal niks over hoe de functionaliteit geïmplementeerd moet zijn. Het zegt alleen wat het eind resultaat moet zijn. Bij het schrijven van je test hoef je in principe dus alleen maar te weten wat je wilt hebben, niet hoe je het wilt hebben. Met plannen heeft het verder weinig te maken.

[ Voor 64% gewijzigd door Janoz op 08-01-2014 10:10 ]

[Gomez12]

pedorus schreef op woensdag 08 januari 2014 @ 01:13:
[...]
Een voorbeeld: Zojuist iets geschreven om bij plaatjes de aspect ratio terug te geven, en aan de hand daarvan goed weer te geven in vakjes. De klasse om de dimensies van plaatjes op te vragen (zonder daadwerkelijk inladen) natuurlijk niet zelf verzonnen, maar bestaande code voor gepakt. Eigenlijk zat daar de core logic, dus verder is er geen unit test nodig volgens mij, dus gewoon direct uitgeprogrammeert en getest in een browser. Wat denk je? Het werkte direct. Voor sommige organisaties zou ik hier een unit test voor hebben moeten schrijven, ivm code coverage, eigenlijk verspilde tijd.

Hoe kom je erbij dat je unit tests zou moeten schrijven voor library's?
Of bedoel je met "bestaande code gepakt" het betere copy-paste werk? Want dan zal je er wel een test voor moeten schrijven.

[pedorus]

Nick_S schreef op woensdag 08 januari 2014 @ 02:11:
Er zijn gelukkig meerdere studies geweest over het effect van TDD.

Nog een overzicht waaruit ongeveer hetzelfde blijkt. Verhoogde hoeveelheid developmentwerk, mogelijk betere kwaliteit op sommige gebieden. (Nog) geen aangetoonde verhoogde productiviteit op de langere termijn.

Megamind schreef op woensdag 08 januari 2014 @ 03:35:
In alle gevallen kan je je software opdelen in aparte taken die je weer apart kan testen.

Janoz schreef op woensdag 08 januari 2014 @ 09:50:
Een test zegt helemaal niks over hoe de functionaliteit geïmplementeerd moet zijn. Het zegt alleen wat het eind resultaat moet zijn. Bij het schrijven van je test hoef je in principe dus alleen maar te weten wat je wilt hebben, niet hoe je het wilt hebben. Met plannen heeft het verder weinig te maken.

Gaan we nu stappen wel of niet los testen? Een unit test, de naam zegt het al, zit in principe op unit niveau. Dit zijn al snel aparte stappen. Enkel hoe weet je nu welke stappen je moet zetten om tot een gewenst eindresultaat (zeg 42) te komen, en welke onderdelen goed samenwerken qua snelheid/geheugengebruik en tussen verschillende threads/machines? Dit doe je door te proberen.

Het lijkt erop alsof jullie denken dat je ieder probleem top-down kan aanpakken, waarna je een gewenst eindresultaat hebt als de deelstappen zijn uitgevoerd. Ik verwijs graag naar deze bijlage van Feynman, een nobelprijswinnaar.

Resteleiro schreef op woensdag 08 januari 2014 @ 07:41:
Als er vooraf geen tests zijn dan komt men er op z'n vroegst tijdens de testfase achter. En daarbij. hoe eerder een bevinding gevonden wordt hoe goedkoper het op te lossen is (kromme van Boehm).

Dat is natuurlijk niet waar, een goede programmeur probeert het eerst zelf uit, en zeg een code review kun je ook eerder doen. Je gaat natuurlijk niet wachten op de testfase met testen. De kromme van Boehm is een mooi concept, maar gaat niet over detectiesnelheid binnen fases en de assen van de kromme zijn overigens ook niet gekwantificeerd, dus daar kun je niet op doorrekenen ofzo.

Gomez12 schreef op woensdag 08 januari 2014 @ 10:21:
Hoe kom je erbij dat je unit tests zou moeten schrijven voor library's?
Of bedoel je met "bestaande code gepakt" het betere copy-paste werk? Want dan zal je er wel een test voor moeten schrijven.

Ook als je een bestaande implementatie pakt, dan nog zijn er regels code die je hebt geschreven om deze implementatie aan te roepen en de resultaten te verwerken en door te geven. Deze regels zijn natuurlijk niet gecoverd door eventuele unit tests van de library (die trouwens, zoals meestal, waarschijnlijk niet bestaand waren).

Janoz schreef op woensdag 08 januari 2014 @ 09:50:
Als je dat nou eens zou kunnen doen, zonder dat je helemaal in de browser rond moet klikken.

Helemaal, als in 2 klikken verwijderd (rechtsklikken, debug). Ten opzichte van het schrijven van een unit test wat evenveel of zelfs meer werk is als de code die echt wat doet.

Echter dat andere stukje code, waar je terecht bestaande en te vertrouwen code/lib voor gebruikt. Stel dat je dat wel zelf had moeten implementeren. Dat lijkt me nu juist wel typisch iets wat je TD kunt doen. Lijstje plaatjes waarvan de de aspect ratio weet in een testje gieten en aan de methode aanbieden. Kun je gewoon die methode implementeren en een paar keer op run drukken zonder dat je een hele gui moet optuigen om het ding aan te roepen.

Eens, maar veel code geeft bijvoorbeeld alleen wat data door of is een stuk minder makkelijk los testbaar.

Juist bij die grote mainframe software heb je voornamelijk met die YADFE te maken waarbij je eigenlijk alleen maar wat data door allemaal tiers trekt zonder dat er werkelijk wat echte functionaliteit geimplementeerd wordt.

Ipv met unit tests zou ik dat graag alleen met zeg soapUI testen.

Je kunt de transformers goed testen die het model in de ene laag omzet naar het model in de volgende laag, maar daarna houd het al snel op.

Inderdaad. Veel werk, weinig winst.

Juist wanneer je met dergelijke interessante software als die van jou bezig gaat wordt het leuk. Je gaat mij echt niet wijsmaken dat jij een stukje code gaat schrijven zonder dat je weet wat het überhaupt moet gaan doen (dus nog los van hoe). Als ik meer dan 10 jaar terug ook meer aan TDD had gedaan dan had ik waarschijnlijk minder lang lopen kloten met bijvoorbeeld al die kleine off by 1 foutjes in mijn applicatie welke bloedvatstructuren uit een 256^3 bytearray aan MRI data had moeten filteren.

Off-by-one fouten kun je ook checken met conditional breakpoint of code reviews. Maar ik zeg ook niet dat ik nooit een test schrijf he. Alleen meestal niet.

Of je nu automatisch of handmatig test, je zult altijd test data nodig hebben. Daarnaast is er genoeg tooling beschikbaar om het hele mock gebeuren uit handen te geven.

Ik mis even de exacte tooling waar je op doelt.

Als ik iets in zijn geheel test, wordt de data zo geladen. Anders moet ik apart testinput maken/inladen en testoutput checken.

[ Voor 28% gewijzigd door pedorus op 08-01-2014 11:03 ]

[Barbas]

pedorus schreef op woensdag 08 januari 2014 @ 10:44:

Dat is natuurlijk niet waar, een goede programmeur probeert het eerst zelf uit, en zeg een code review kun je ook eerder doen. Je gaat natuurlijk niet wachten op de testfase met testen. De kromme van Boehm is een mooi concept, maar gaat niet over detectiesnelheid binnen fases en de assen van de kromme zijn overigens ook niet gekwantificeerd, dus daar kun je niet op doorrekenen ofzo.

Het was ook wat gechargeerd. Statisch testen is ook belangrijk en daar heb je ook gelijk in. Er is in mijn ogen echter wel een wezenlijk verschil tussen iets uitproberen of iets testen. Hoe vaak ik zaken gehoord heb als "lokaal doet ie het gewoon" maar bij een release naar test de boel klapt.

[kenneth]

pedorus schreef op woensdag 08 januari 2014 @ 10:44:
Off-by-one fouten kun je ook checken met conditional breakpoint of code reviews. Maar ik zeg ook niet dat ik nooit een test schrijf he. Alleen meestal niet.

Maar ga je bij iedere aanpassing van je code in de weer met breakpoints? Het mooie van unit tests is natuurlijk dat de uitvoertijd enorm kort is waardoor het opnieuw draaien van alle tests sneller is dan de overweging of het wel nodig is

Ik heb al aardig wat bugs opgespoord vóór de acceptatietests door blind weer alle unit tests te draaien en dan faalde een test die toch echt goed zou moeten gaan omdat ik daar toch echt niets had aangepast ... oeps, toch fout. Dat wil ik echt nooit meer met de hand doen.

Ik mis even de exacte tooling waar je op doelt.

Mocking frameworks?

C#:

var mock = new Mock<IMyInterface>(); mock.Setup(x => x.MyMethod(5)).Returns(25);

Mocken is meestal een nobrainer. En voor data ondersteunt xUninet.net data-driven tests (met als datasource alles van Excel tot SQL Server), je hebt AutoFixture om snel je objecten te vullen met data, enzovoort.

[creator1988]

kenneth schreef op woensdag 08 januari 2014 @ 11:44:
[...]
Maar ga je bij iedere aanpassing van je code in de weer met breakpoints? Het mooie van unit tests is natuurlijk dat de uitvoertijd enorm kort is waardoor het opnieuw draaien van alle tests sneller is dan de overweging of het wel nodig is

Laten we wel wezen, geen TDD doen en helemaal geen tests schrijven is natuurlijk wel wezenlijk wat anders. Ik schrijf ook tests, maar meestal niet vooraf.

[Janoz]

pedorus schreef op woensdag 08 januari 2014 @ 10:44:


Gaan we nu stappen wel of niet los testen? Een unit test, de naam zegt het al, zit in principe op unit niveau. Dit zijn al snel aparte stappen. Enkel hoe weet je nu welke stappen je moet zetten om tot een gewenst eindresultaat (zeg 42) te komen, en welke onderdelen goed samenwerken qua snelheid/geheugengebruik en tussen verschillende threads/machines? Dit doe je door te proberen.

Hoe groot of hoe klein je de units neemt vind ik persoonlijk niet zo belangrijk. Ik neem ze zo groot als ik handig vindt (waarbij er ook genoeg stukken zijn die dubbel afgedekt worden). Maar goed. In dit geval zou je unittest niet meer zijn dan:

assert.equals(42.subject.someImplementation());



Hoe je daartoe komt maakt voor de test niet uit. Bijkomend voordeel is dat je er heel makkelijk wat profiling van maakt waardoor je juist vanuit je unittest kunt gaan proberen.

Het lijkt erop alsof jullie denken dat je ieder probleem top-down kan aanpakken, waarna je een gewenst eindresultaat hebt als de deelstappen zijn uitgevoerd. Ik verwijs graag naar deze bijlage van Feynman, een nobelprijswinnaar.

Problemen waar ik tegen aanloop over het algemeen wel. Ik ben erg benieuwd naar een unit of work waar jij recentelijk aan begonnen bent waarbij je eigenlijk geen idee had wat de uitkomst zou moeten zijn.

Dat is natuurlijk niet waar, een goede programmeur probeert het eerst zelf uit.

Uitproberen kun je heel makkelijk aanslingeren vanuit je test

Ook als je een bestaande implementatie pakt, dan nog zijn er regels code die je hebt geschreven om deze implementatie aan te roepen en de resultaten te verwerken en door te geven. Deze regels zijn natuurlijk niet gecoverd door eventuele unit tests van de library (die trouwens, zoals meestal, waarschijnlijk niet bestaand waren).

Ik begrijp je niet helemaal. Als je dit (perse) wilt testen heb je een mock van die lib die bij een gegeven filehandle een bepaald aspect ratio uitkomst terug geeft. Vervolgens kun je keurig testen of aan de voorkant de juiste uitkomst komt. Waar je weg haalt dat die library je eigen code zou moeten testen is mij een raadsel.

Helemaal, als in 2 klikken verwijderd (rechtsklikken, debug). Ten opzichte van het schrijven van een unit test wat evenveel of zelfs meer werk is als de code die echt wat doet.

Ik 1, ik druk op de play van het junitschermpje van mijn IDE. Ik heb dan gelijk ook de rest van mijn applicatie weer gevalideerd.

Eens, maar veel code geeft bijvoorbeeld alleen wat data door of is een stuk minder makkelijk los testbaar.

Als het alleen om data doorgeven gaat dan is dat natuurlijk triviaal. Een simpele integratietest lijkt me dan meer dan genoeg (SoapUI voorbeeld). Maar soms gebeurt er in die keten nog wel eens wat extras.

Lastig te testen code is (muv GUI achtige dingetjes) vaak nog best te refactoren naar stuk beter te testen code.

Ipv met unit tests zou ik dat graag alleen met zeg soapUI testen.

Leuke integratie test, maar wanneer die fout gaat, Ligt het dan aan het stukje dat de xml omzet in je value object, de businesslogic die daar wat mee doet, de transformatie naar persistance objecten, je ORM, de businesslogic die het resultaat aanmaakt of de marshaller die dat weer naar xml omzet ?

Een dergelijke test kun je pas uitvoeren als de hele keten af is. Een test die controleert of een VO goed gemarshald wordt naar de te verwachten XML of een unittest die controleert of een VO object goed wordt omgezet in een persistance object kun je al veel eerder draaien.

Inderdaad. Veel werk, weinig winst.

De transformers worden sowieso gemaakt. De bijbehorende unittest is redelijk triviaal.

Off-by-one fouten kun je ook checken met conditional breakpoint of code reviews. Maar ik zeg ook niet dat ik nooit een test schrijf he. Alleen meestal niet.

Zodra je vreemd gedrag ziet steppen door je complete applicatie om te kunnen zien welke loop nu eigenlijk die off by one fout heeft (of dat het gewoon toch ergens anders ligt) lijkt me een stuk arbeidsintensiever dan voor elk van die lussen een keer 3 simpele testjes met wat bordercases schrijven.

Ik mis even de exacte tooling waar je op doelt.

Als ik iets in zijn geheel test, wordt de data zo geladen. Anders moet ik apart testinput maken/inladen en testoutput checken.

Je hebt dus al code die de data laad. Geen extra werk dus . Daarnaast kun je voor je unittest een heerlijk herhaalbare situatie creeeren doordat je elke keer met dezelfde uitgangssituatie start. (ipv zo'n testomgeving waarbij de tester ondertussen al zijn hele arsenaal aan te verzinnen namen heeft gepropt om telkens het opvoeren van die nieuwe gebruiker te testen.

Mocking tools zijn verder al eerder aangehaald.

[Megamind]

Janoz schreef op woensdag 08 januari 2014 @ 13:43:
[...]

Hoe groot of hoe klein je de units neemt vind ik persoonlijk niet zo belangrijk. Ik neem ze zo groot als ik handig vindt (waarbij er ook genoeg stukken zijn die dubbel afgedekt worden). Maar goed. In dit geval zou je unittest niet meer zijn dan:

assert.equals(42.subject.someImplementation());



Hoe je daartoe komt maakt voor de test niet uit. Bijkomend voordeel is dat je er heel makkelijk wat profiling van maakt waardoor je juist vanuit je unittest kunt gaan proberen.

Daarnaast regel 1:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

[pedorus]

Resteleiro schreef op woensdag 08 januari 2014 @ 11:26:
Hoe vaak ik zaken gehoord heb als "lokaal doet ie het gewoon" maar bij een release naar test de boel klapt.

Laatste keer dat ik dit had, had het project een code coverage van 90+%. Oorzaak lag aan de setup van de testomgeving. Ik zie niet in hoe tests dit hadden kunnen voorkomen..

kenneth schreef op woensdag 08 januari 2014 @ 11:44:
Mocking frameworks?

C#:

var mock = new Mock<IMyInterface>(); mock.Setup(x => x.MyMethod(5)).Returns(25);

Mocken is meestal een nobrainer. En voor data ondersteunt xUninet.net data-driven tests (met als datasource alles van Excel tot SQL Server), je hebt AutoFixture om snel je objecten te vullen met data, enzovoort.

Wat is het leven toch mooi als de input en outputs uit enkele getallen bestaan. Enkel nu hebben we wat testdata nodig. Een voorbeeld: als input de posts van vandaag in dit topic bijvoorbeeld, als objecten uit database. We willen een lijstje terug met een top 10 van de meest gebruikte woorden (een woord gedefinieerd als \w+), hoe vaak ze gebruikt zijn, en welke poster ze het meest gebruikte. Graag de test case(s) van te voren schrijven, voordat de code er is. TDD tenslotte. Denk je dat de tijd die deze test case(s) maken kost zich zal terugverdienen?

Janoz schreef op woensdag 08 januari 2014 @ 13:43:
Maar goed. In dit geval zou je unittest niet meer zijn dan:

assert.equals(42.subject.someImplementation());



Hoe je daartoe komt maakt voor de test niet uit.

offtopic:
compile error

Dit is nu juist het probleem. Je weet niet of er iets is geschreven dat voldoet aan de test cases, of dat er is begrepen wat er geprogrammeerd moest worden en dit is geschreven. Is de juiste vraag nu echt gesteld aan de computer, of is alleen het juiste antwoord gegeven?

Problemen waar ik tegen aanloop over het algemeen wel. Ik ben erg benieuwd naar een unit of work waar jij recentelijk aan begonnen bent waarbij je eigenlijk geen idee had wat de uitkomst zou moeten zijn.

Stel dat je dit probleem wil oplossen: Maak een samenvatting van wat er zich vandaag in de DevSchuur af heeft gespeeld in maximaal 500 woorden. Update deze samenvatting steeds zsm.

Ik begrijp je niet helemaal. Als je dit (perse) wilt testen heb je een mock van die lib die bij een gegeven filehandle een bepaald aspect ratio uitkomst terug geeft. Vervolgens kun je keurig testen of aan de voorkant de juiste uitkomst komt. Waar je weg haalt dat die library je eigen code zou moeten testen is mij een raadsel.

Veel code doet niet zo heel veel en pompt wat data rond, zoals in dit voorbeeldje. Daar zijn geen bestaande testcases voor, want dan was de code hiervoor er vast ook al. Ga je hier eerst test cases voor schrijven? Wat als je bijvoorbeeld de situatie hebt van een simpel webformulier om wat data in een database te krijgen, eerst test cases? En wat testen die dan?

Ik 1, ik druk op de play van het junitschermpje van mijn IDE. Ik heb dan gelijk ook de rest van mijn applicatie weer gevalideerd.

Klinkt als een eerlijk vergelijk. Die testcases hebben zichzelf geschreven?

Zodra je vreemd gedrag ziet steppen door je complete applicatie om te kunnen zien welke loop nu eigenlijk die off by one fout heeft (of dat het gewoon toch ergens anders ligt) lijkt me een stuk arbeidsintensiever dan voor elk van die lussen een keer 3 simpele testjes met wat bordercases schrijven.

Hoe komen we aan wat complexere input en outputdata van te voren?

Je hebt dus al code die de data laad. Geen extra werk dus .

Regels code schrijven kost werk. Code voor inladen vanaf een andere plek ook. Bestandjes met vaste data klaarzetten ook.

[Caelorum]

pedorus schreef op woensdag 08 januari 2014 @ 15:08:
[...]
[...] Wat is het leven toch mooi als de input en outputs uit enkele getallen bestaan. Enkel nu hebben we wat testdata nodig. Een voorbeeld: als input de posts van vandaag in dit topic bijvoorbeeld, als objecten uit database. We willen een lijstje terug met een top 10 van de meest gebruikte woorden (een woord gedefinieerd als \w+), hoe vaak ze gebruikt zijn, en welke poster ze het meest gebruikte. Graag de test case(s) van te voren schrijven, voordat de code er is. TDD tenslotte. Denk je dat de tijd die deze test case(s) maken kost zich zal terugverdienen?[...]

Je beschrijft hier niet 1 ding, maar meerdere dingen. Die kan je dus ook gewoon apart beschrijven in tests en de functionaliteit afzonderlijk maken. En nee het zal zich niet meteen terugverdienen, maar wellicht later in het traject wel waar 1 klein ding dit alles onderuit kan schoppen. Dat zie je dan meteen terug in de tests. Zonder de tests niet
Overigens betekent TDD nadrukkelijk niet dat je het hele systeem in een keer gaat proberen te beschrijven in tests en het dan gaat schrijven.

[...] Dit is nu juist het probleem. Je weet niet of er iets is geschreven dat voldoet aan de test cases, of dat er is begrepen wat er geprogrammeerd moest worden en dit is geschreven. Is de juiste vraag nu echt gesteld aan de computer, of is alleen het juiste antwoord gegeven?[...]

Dat maakt niet uit. De functionaliteit is er. Daarnaast heb je meerdere tests die allen het gewenste resultaat beschrijven. Als er gewoon "return 42" in die methode staat en daarmee is alles goed dan heb je het gewenste resultaat niet goed beschreven.

Hoe komen we aan wat complexere input en outputdata van te voren?

Een goede omschrijving van het gewenste resultaat geeft al de benodigde input en output. Je doet TDD ook niet om de initiële tijd van ontwikkelen korter te maken, maar om bugs die er in sluipen snel te kunnen identificeren en terugkerende bugs te voorkomen.

[...] Regels code schrijven kost werk. Code voor inladen vanaf een andere plek ook. Bestandjes met vaste data klaarzetten ook.

Ja, dat kost tijd. Er moet een afweging worden gemaakt of het die tijd waard is.

[ Voor 3% gewijzigd door Caelorum op 08-01-2014 15:23 ]

[pedorus]

Caelorum schreef op woensdag 08 januari 2014 @ 15:21:
Je beschrijft hier niet 1 ding, maar meerdere dingen. Die kan je dus ook gewoon apart beschrijven in tests en de functionaliteit afzonderlijk maken. En nee het zal zich niet meteen terugverdienen, maar wellicht later in het traject wel waar 1 klein ding dit alles onderuit kan schoppen. Dat zie je dan meteen terug in de tests. Zonder de tests niet
Overigens betekent TDD nadrukkelijk niet dat je het hele systeem in een keer gaat proberen te beschrijven in tests en het dan gaat schrijven.

Zie er zoveel dingen in als je wil, vraag is hoe jullie zoiets met TDD zouden aanpakken. Zonder TDD is het echt niet zoveel werk, voor mij niet iig.

Als er gewoon "return 42" in die methode staat en daarmee is alles goed dan heb je het gewenste resultaat niet goed beschreven.

Kennelijk niet inderdaad

[HMS]

Trouwens, een belangrijk punt wat nog niet aangestipt is. Omdat je test first werkt is het ook nodig om je diagnostics goed te krijgen, je moet aan de hand van de output van je unit test weten wat er fout gaat.

Dus iets als:

code:

Write failing test -> Make diagnostics clear -> Make the test pass -> Refactor -> Repeat.

Daarnaast @pedorus, als de test data al voor handen is:

1. Het verkrijgen van posts. Initieel kan dit wel door een fake te gebruiken die de posts in het correcte formaat returned. (Aanname mijnerzijds: het verkrijgen van de posts is triviaal).
2. Het splitsen van elke post in een set van tuples: <woord, poster> (map).
3. Het verzamelen van alle tuples <woord, poster> en verwerken naar een set <woord, <poster, count>> (dus voor elke woord hebben we voor elke poster die dat gebruikt een counter) (reduce).

Dus zeer waarschijnlijk gebruik je een set van posts waarvan je weet welke poster welke woord hoe vaak gebruikt (of je maakt zelf wat test data) zodat je kan kijken of je dit goed geimplementeerd hebt.

Al deze componenten kan je los van elkaar testen door er test data in te gooien. Daarnaast heb je nog een integratie test die de hele keten test.

[ Voor 8% gewijzigd door HMS op 08-01-2014 15:54 ]

[pedorus]

Hmm, ik zie daar geen top 10 uit komen.. Ik zou eerst direct een map woord->(aantal, (map poster->aantal)) maken, en dan daarover de top 10 bepalen en de top 1 van de posters voor die top 10. Tenzij je zoveel data gaat gebruiken dat het over meerdere machines moet worden opgesplitst, dan is die 2e stap wellicht nuttig.. Maar goed, zoveel staat er nu ook niet in dit topic, dus dat lijkt me niet.

In ieder geval, wat je ziet is dat de testcases en integratietests maken veel meer tijd gaat kosten dan dat ik aan uitprogrammeren van dit opdrachtje kwijt zou zijn.

[HMS]

Klopt, maar dan is dit specifieke probleem ook beter op te lossen in een functionele programmeer taal dan in een object georienteerde .

[Caelorum]

pedorus schreef op donderdag 09 januari 2014 @ 14:58:
[...] In ieder geval, wat je ziet is dat de testcases en integratietests maken veel meer tijd gaat kosten dan dat ik aan uitprogrammeren van dit opdrachtje kwijt zou zijn.

Nogmaals niemand beweert hier dat het ontwikkelen volgens TDD sneller is of überhaupt net zo snel. De winst zit hem ook niet in de initiële ontwikkeltijd, maar op de mogelijke tijdswinst op de lange termijn en onderhoudbaarheid en dat soort zaken.

[Corniel]

Ik ben al lange tijd ontwikkelaar, en ook al geruime tijd voorstander van TDD. Het is zeker niet altijd geschikt, en het geeft geen volledig beeld over de robuustheid, betrouwbaarheid, en juistheid van de code (kwaliteit is zo'n hol begrip), maar het komt wel dicht in de buurt.

De reden waarom ik er ooit mee begon is dat ik heel gelukkig werd van het kunnen debuggen van kleine stukken code. Niet alleen helpt dat met het snel oplosen van bugs, het geeft je ook inzicht in hoe een taal werkt. Ik blijf dat een van meest effectieve manieren vinden om een taal te leren.

Het grote voordeel van TDD is/zou moeten zijn dat je niet blind gaat op functionaliteit die je (nog) niet nodig hebt. Zeker als je met jezelf afspreekt (of met je collega's) dat je een code-coverage moet halen van zeg 80%.

TDD is imho ook heel prettig JUIST om die corner-cases te testen. Of om in praktijk te ondervinden of de bedachte API werkt. Ja, en soms moet je dan ook je tests herschrijven, omdat aanpassingen in de API zijn bedacht, maar daardoor wordt de code doorgaans beter te begrijpen/gebruiken.

En zolang je aan het demo-en bent is het niet altijd nuttig. Maar het zou niet voor het eerst zijn dat een demo toch direct wordt uitgebouwd tot iets wat in productie moet...

[Gomez12]

pedorus schreef op donderdag 09 januari 2014 @ 14:58:
Hmm, ik zie daar geen top 10 uit komen.. Ik zou eerst direct een map woord->(aantal, (map poster->aantal)) maken, en dan daarover de top 10 bepalen en de top 1 van de posters voor die top 10. Tenzij je zoveel data gaat gebruiken dat het over meerdere machines moet worden opgesplitst, dan is die 2e stap wellicht nuttig.. Maar goed, zoveel staat er nu ook niet in dit topic, dus dat lijkt me niet.

In ieder geval, wat je ziet is dat de testcases en integratietests maken veel meer tijd gaat kosten dan dat ik aan uitprogrammeren van dit opdrachtje kwijt zou zijn.

Maar hoe weet jij nou of wat jij produceert goed is? En of het ook goed blijft gaan bij topics die boven de 10.000 posts gaan?
Of veel leuker, als je collega dit geschreven heeft hoe weet jij dan of het werkt?

Het hele test-verhaal is uiteraard 100% overbodig als je enkel in je eentje programmeert en nooit een fout maakt... Maar dat is niet de praktijk.

[pedorus]

Gomez12 schreef op donderdag 09 januari 2014 @ 16:45:
[...]

Maar hoe weet jij nou of wat jij produceert goed is? En of het ook goed blijft gaan bij topics die boven de 10.000 posts gaan?
Of veel leuker, als je collega dit geschreven heeft hoe weet jij dan of het werkt?

Het hele test-verhaal is uiteraard 100% overbodig als je enkel in je eentje programmeert en nooit een fout maakt... Maar dat is niet de praktijk.

Hoe precies vangt TDD deze problemen op? Weet je dan wel zeker dat het werkt? Maak je een test met 10000+ posts (lange draaitijd)?

In de tijd die TDD kost, had ik al twee verschillende implementaties kunnen hebben, die door twee mensen een code review hadden gekregen. Geeft TDD dan meer zekerheid, of geven die twee implementaties meer zekerheid?

Caelorum schreef op donderdag 09 januari 2014 @ 15:58:
[...]

Nogmaals niemand beweert hier dat het ontwikkelen volgens TDD sneller is of überhaupt net zo snel. De winst zit hem ook niet in de initiële ontwikkeltijd, maar op de mogelijke tijdswinst op de lange termijn en onderhoudbaarheid en dat soort zaken.

Die winst is dus helaas niet (wetenschappelijk) aangetoond. Vandaag nog een open source project in gebruik genomen welke unit tests had. Opmerking erbij: deze zijn stuk op dit moment. De library doet het gelukkig wel. Dit is natuurlijk vreemd. Als die testen er vooral voor de onderhoudbaarheid zijn, en ze waren reeds aanwezig, en ze deden het eerder wel, waarom is dit niet doorgezet?

[Caelorum]

pedorus schreef op donderdag 09 januari 2014 @ 17:08:
[...]
Hoe precies vangt TDD deze problemen op? Weet je dan wel zeker dat het werkt? Maak je een test met 10000+ posts (lange draaitijd)? [...] Geeft TDD dan meer zekerheid, of geven die twee implementaties meer zekerheid? Dat is het punt waarop je blij gaat zijn als al die tests er wel zijn. Het is een stukje zekerheid die je nalaat aan alle mensen die na jouw die code moeten aanraken. Het valt en staat alleen wel met de correctheid van de tests.

Wat als een ex-collega nu een mooi algoritme maakt die het goed doet, maar down-the-road moet jij extra functionaliteit aanbrengen zonder bestaande functionaliteit te breken. Weet jij dan nog wat die functionaliteit was en hoe je het moet testen, zodat je zeker weet dat alles nog werkt naar behoren?

[...] Die winst is dus helaas niet (wetenschappelijk) aangetoond. Vandaag nog een open source project in gebruik genomen welke unit tests had. Opmerking erbij: deze zijn stuk op dit moment. De library doet het gelukkig wel. Dit is natuurlijk vreemd. Als die testen er vooral voor de onderhoudbaarheid zijn, en ze waren reeds aanwezig, en ze deden het eerder wel, waarom is dit niet doorgezet?

Ja, luister. We gaan er wel van uit dat mensen fatsoenlijke tests kunnen maken en ook daadwerkelijk op de goede manier test driven ontwikkelen. Je kan zelfs als je TDD probeert te werken (of zegt het te doen) fouten maken.
Ik ontwikkel zelf niet volgens een TDD werkwijze overigens. Ik kap er meestal ook mee na een dag of twee, mede omdat ik niet fatsoenlijke tests kan schrijven. Ik ben nog wel van plan me daar eens goed in te verdiepen hoor, maar tijd is ook kostbaar

[ Voor 6% gewijzigd door Caelorum op 09-01-2014 17:41 ]

[Gomez12]

Caelorum schreef op donderdag 09 januari 2014 @ 17:40:
[...]
Ja, luister. We gaan er wel van uit dat mensen fatsoenlijke tests kunnen maken en ook daadwerkelijk op de goede manier test driven ontwikkelen. Je kan zelfs als je TDD probeert te werken (of zegt het te doen) fouten maken.
Ik ontwikkel zelf niet volgens een TDD werkwijze overigens. Ik kap er meestal ook mee na een dag of twee, mede omdat ik niet fatsoenlijke tests kan schrijven. Ik ben nog wel van plan me daar eens goed in te verdiepen hoor, maar tijd is ook kostbaar

Falende tests zijn opzich ook niet erg hoor, die geven ook informatie...

Zo'n falende test kan bijv in een erg randgeval zitten wat erg veel moeite kost om op te lossen.

Schrijf jij de test en krijg je een bugmelding binnen met zo'n randgeval dan hoef je in ieder niet te bughunten, dan kan je gelijk zeggen dat het een randgeval is wat pas over xxxx tijd mogelijk gefixed gaat worden omdat het zo'n extreem randgeval is.

[Caelorum]

Een test hoort nooit te falen

[incaz]

pedorus schreef op donderdag 09 januari 2014 @ 17:08:
[...]
In de tijd die TDD kost, had ik al twee verschillende implementaties kunnen hebben, die door twee mensen een code review hadden gekregen.

Dat geloof ik niet Tests schrijven is niet zoveel werk en code review is dat wel. No way dat die cijfers werkelijk standhouden. En dan niet komen met 'jamaar het was maar een voorbeeld' want het gaat juist om die cijfers.

Caelorum: een test hoort hopelijk te falen als je code niet goed is Anders kun je de hele boel ook wel in een try-catch{//do nothing} mieteren.

[Caelorum]

incaz schreef op donderdag 09 januari 2014 @ 18:47:
[...] Caelorum: een test hoort hopelijk te falen als je code niet goed is Anders kun je de hele boel ook wel in een try-catch{//do nothing} mieteren.

Ja ^^ Ik bedoelde ook dat een test die faalt by design gewoon niet hoort. Dat was hoe ik zijn opmerking las. Kan het ook compleet verkeerd hebben begrepen hoor.

[Oxidda]

Ik heb bij 1 project TDD gebruikt. Het ging om een heel erg flexibel import tooltje. Je kon in dit tooltje op basis van instellingen in de database (Heel veel mogelijkheden, CSV, Excel etc. dan elke kolom instellen ga zo maar door) bepaalde bestanden inlezen.

Voor dit projectje heb ik TDD gebruikt, mede omdat de functionele beschrijving bij dit project heel erg goed was beschreven. Ik kon letterlijk al mijn test cases uit de functionele beschrijving halen. Met als gevolg dat de software relatief weining fouten bevatte.

Echter zit ik met de meeste producten die ik bouw met onduidelijke beschrijvingen waardoor er om de haverklap wat veranderd. Dus dan zou ook de unit test elke keer mee moeten veranderen. Dat voel ik dan weer als nadeel: Specs onduidelijk, Unit Test maken met onduidelijke specs. Hoe je het ook ziet, de Unit Test en de code zijn dan beide fout (Ondanks dat de unit test "Goed" gaat).

Ik weet het je zou alleen aan een product moeten beginnen waarvna de functionaliteiten duidelijk op papier staan, in de praktijk komt dat alleen zelden voor. Maar toch kan ook TDD daar bij helpen, een van de doelen zou moeten zijn om na te gaan denken over de functionaliteit : "Is het wel logisch" (om een voorbeeld te noemen).

Ik zou alleen TDD houden op de achterkant van de software en niet op de UI. Dingen als "Het ziet er niet mooi uit" kun je niet testen met een automatische test.

Zelf doe ik het dus op het moment niet. Maar ik ben er wel redelijk positief over (Men vind men hier ook af en toe vervelend als ik weer eens begin over Unit Tests, want zo ervaren de meeste ontwikkelaars het)

[Gomez12]

Caelorum schreef op donderdag 09 januari 2014 @ 18:58:
[...]

Ja ^^ Ik bedoelde ook dat een test die faalt by design gewoon niet hoort. Dat was hoe ik zijn opmerking las. Kan het ook compleet verkeerd hebben begrepen hoor.

De test faalt niet bij design, maar er is simpelweg geen tijd/geld beschikbaar om de test te laten slagen.

Het is bekend dat de test faalt (dus als iemand aan komt zetten met een soortgelijk geval dan weet je gelijk waar het aan ligt en als de test onverwacht toch slaagt dan is de case ook opgelost) alleen is er geen tijd / noodzaak om de code te fixen

[whoami]

pedorus schreef op woensdag 08 januari 2014 @ 15:08:
[...]


Wat is het leven toch mooi als de input en outputs uit enkele getallen bestaan. Enkel nu hebben we wat testdata nodig. Een voorbeeld: als input de posts van vandaag in dit topic bijvoorbeeld, als objecten uit database. We willen een lijstje terug met een top 10 van de meest gebruikte woorden (een woord gedefinieerd als \w+), hoe vaak ze gebruikt zijn, en welke poster ze het meest gebruikte. Graag de test case(s) van te voren schrijven, voordat de code er is. TDD tenslotte. Denk je dat de tijd die deze test case(s) maken kost zich zal terugverdienen?

Dit is al geen unit-test meer.
Je zou voor bovenstaande userstory wel volgende unittest kunnen schrijven:
- geef een lijst van de 10 meest gebruikte woorden, gegeven een verzameling tekst. Vanwaar die tekst komt, maakt niet uit.

Dit gaat al veel sneller geschreven zijn, en evengoed bruikbaar binnen TDD.

Regels code schrijven kost werk. Code voor inladen vanaf een andere plek ook. Bestandjes met vaste data klaarzetten ook.

Achteraf een dag zitten debuggen kost ook werk & tijd.
Manueel testen van de codebase na een paar wijzigingen om na te gaan of alles nog werkt zoals het hoort, kost ook tijd & moeite...

[whoami]

pedorus schreef op donderdag 09 januari 2014 @ 17:08:
[...]

Hoe precies vangt TDD deze problemen op? Weet je dan wel zeker dat het werkt? Maak je een test met 10000+ posts (lange draaitijd)?
In de tijd die TDD kost, had ik al twee verschillende implementaties kunnen hebben, die door twee mensen een code review hadden gekregen. Geeft TDD dan meer zekerheid, of geven die twee implementaties meer zekerheid?

En na een code-review ben je zeker of de implemenatie werkt ? Incl. alle corner-cases ?

[SPee]

Ik denk dat TDD niet de hele tijd voor een project werkt, maar dat het per keer moet worden gekeken of dit mogelijk is.
Bij vele nieuwe dingen is het niet mogelijk om eerst de test te maken (behalve wanneer het zo strict wordt bepaalt dat de implementatie al in de analyse is gemaakt, maar dat is geen coderen ). In dat geval zou je tijdens of direct na de implementatie de tests moeten schrijven.
Maar bij specifieke aanpassingen kan dit wel. Dan is dat een aanpassing op een bestaande case waar je dat wel kan doen.

Of iedereen komt er anders tegenaan wat het inhoud. Dan denkt de een dat je nog geen letter code hebt geschreven maar de ander dat dat wel alvast kan.

[pedorus]

incaz schreef op donderdag 09 januari 2014 @ 18:47:
Dat geloof ik niet Tests schrijven is niet zoveel werk en code review is dat wel. No way dat die cijfers werkelijk standhouden. En dan niet komen met 'jamaar het was maar een voorbeeld' want het gaat juist om die cijfers.

Dit zag ik laatst, klein beetje werk:
-Daadwerkelijke programmeerwerk: 8u
-Unit tests maken: 8u
-Bestaande unit test fixen: 2u
-Mocks en integratietest maken: 8u
-Code review: 4u
(eerdere/latere fases, verdere tests, documentatie, meetings, deployen, e.d. zit hier niet in)

Tenzij iemand handige tooling heeft om die test cases binnen een paar uur te maken, zie ik dat in dit voorbeeld ook makkelijk gebeuren. (Kom maar op met die tools! )

whoami schreef op donderdag 09 januari 2014 @ 20:42:
[...]
Dit is al geen unit-test meer.

Nee, het is een opdrachtje. Ik kan toch niet zeggen, laten we de opdracht maar fors versimpelen, want ik wil TDD gebruiken?

whoami schreef op donderdag 09 januari 2014 @ 20:45:
[...]
En na een code-review ben je zeker of de implemenatie werkt ? Incl. alle corner-cases ?

Natuurlijk niet. Maar het gaat erom om de tijd zo efficiënt mogelijk te besteden. Welke methode levert in zo weinig mogelijk tijd zoveel mogelijk (kwaliteits)winst op? Als velen iets schitterend vinden, het al tijden bestaat, maar maar weinigen het daadwerkelijk doen, dan is dit wellicht een indicatie. Naast de reeds aangehaalde studies.

[Oxidda]

Der zijn wel pogingen geweest om automatisch unit tests te genereren op basis van source code , ik geloof alleen dat de meeste zijn gestrand. Ik dacht dat PEX er een was.

[Gomez12]

Ik heb het idee dat er hier simpelweg 2 discussies door elkaar heenlopen :
1 : De TDD discussie (waar weer verschillende interpretaties zijn wat TDD inhoud)
2 : De Pedorus discussie die uberhaupt geen testen wenst te maken.

SPee schreef op donderdag 09 januari 2014 @ 21:10:
Bij vele nieuwe dingen is het niet mogelijk om eerst de test te maken (behalve wanneer het zo strict wordt bepaalt dat de implementatie al in de analyse is gemaakt, maar dat is geen coderen ). In dat geval zou je tijdens of direct na de implementatie de tests moeten schrijven.

Tja, dat is natuurlijk ook weer zo. Het is afhankelijk van je analyse / het klantniveau.
Schrijf je een highlevel analyse dan ga je er ook enkel maar highlevel tests op kunnen schrijven (anders wordt het echt zinloos om TDD te gaan doen)

Maar het is daarnaast ook afhankelijk van de groote / het belang van het project.Moet jij een one-off iets maken wat volgende week moet draaien dan is unit-testing uberhaupt twijfelachtig imho. Maar moet jij een ding bouwen wat 3 jaar moet draaien en waar continue wijzigingen in door moeten komen, tja dan kan je maar beter wel testen gaan maken.

pedorus schreef op donderdag 09 januari 2014 @ 22:43:
[...]
Dit zag ik laatst, klein beetje werk:
-Daadwerkelijke programmeerwerk: 8u
-Unit tests maken: 8u
-Bestaande unit test fixen: 2u
-Mocks en integratietest maken: 8u
-Code review: 4u
(eerdere/latere fases, verdere tests, documentatie, meetings, deployen, e.d. zit hier niet in)

Tenzij iemand handige tooling heeft om die test cases binnen een paar uur te maken, zie ik dat in dit voorbeeld ook makkelijk gebeuren. (Kom maar op met die tools! )

En hoeveel uur gaat er in het totale project zitten? Als er op dat project gewoon 2000 uur per jaar geschreven wordt dan ga je imho zonder unit tests echt wel meer tijd verspillen in de toekomst omdat er ergens wel een edge case opduikt die zonder tests gewoon rustig 30 uur uitzoekwerk wordt (omdat je totaal geen idee hebt waar te beginnen)

[...]
Nee, het is een opdrachtje. Ik kan toch niet zeggen, laten we de opdracht maar fors versimpelen, want ik wil TDD gebruiken?

Ik zou zeggen je moet de opdracht uberhaupt al versimpelen naar meerdere kleine opdrachten, als je dit in 1 procedure gaat stouwen dan heb je wmb geen idee waar je mee bezig bent.

[...]
Natuurlijk niet. Maar het gaat erom om de tijd zo efficiënt mogelijk te besteden.

Ah, het gaat jou om kwantiteit en niet om kwaliteit dus.

Als velen iets schitterend vinden, het al tijden bestaat, maar maar weinigen het daadwerkelijk doen, dan is dit wellicht een indicatie.

Ik denk dat er wel genoeg mensen zijn die aan unit-tests doen, enkel in veel verschillende vormen en met vele definities van units etc.

Of laat ik het anders zeggen : Als jij meer als 100 bugs in 1 project hebt gehad dan kom je er wmb niet meer mee weg om enkel maar te gaan breakpointen. Dan wordt bug 151 gelijk aan bug 1 en fix voor 151 veroorzaakt weer bug 2 etc. Jij gaat niet alle 100 eerder gemelde bugs breakpointen om te zien of die niet terug gekomen zijn, met tests hoef je dit ook niet te doen. Het gebeurt gewoon automatisch in het aanmaken van een build en het zou perfect zijn als je nooit tegen die tests aanloopt, maar de praktijk met grotere projecten en meer mensen is dat bugs gaan terugkomen (bijv doordat progger 1 gewoon een structurele denkfout maakt qua het benaderen van classe x teerwijl progger 2 dat al 3x gefixed heeft)

[pedorus]

Oxidda schreef op donderdag 09 januari 2014 @ 23:27:
Der zijn wel pogingen geweest om automatisch unit tests te genereren op basis van source code , ik geloof alleen dat de meeste zijn gestrand. Ik dacht dat PEX er een was.

Microsoft heeft wel wat aardige tools gemaakt inderdaad. CHESS bijvoorbeeld ook.

De code gebruiken gaat hem met TDD waarschijnlijk niet worden.

Gomez12 schreef op donderdag 09 januari 2014 @ 23:30:
2 : De Pedorus discussie die uberhaupt geen testen wenst te maken.

Onzin, zie boven. Ik heb hooguit iets tegen blind unit tests maken. En ik zet voorop hoe iets geprogrammeerd kan worden, ipv hoe je iets gaat testen. Een nog wat onbelicht aspect in dit draadje is hoe TDD veelal leidt tot een ander design, imo een minder gewenst design.

offtopic:
Verder was dit topic een dag dood, dus ik slinger hem ff aan

En hoeveel uur gaat er in het totale project zitten? Als er op dat project gewoon 2000 uur per jaar geschreven wordt dan ga je imho zonder unit tests echt wel meer tijd verspillen in de toekomst omdat er ergens wel een edge case opduikt die zonder tests gewoon rustig 30 uur uitzoekwerk wordt (omdat je totaal geen idee hebt waar te beginnen)

Dit is simpelweg niet waar. Ging om een kleine webservice van ~200 uur. Hierna zijn ook nog genoeg soapUI en andere testcases gemaakt, die mijns inziens de eerdere tests grotendeels overbodig hebben gemaakt.

Ik zou zeggen je moet de opdracht uberhaupt al versimpelen naar meerdere kleine opdrachten, als je dit in 1 procedure gaat stouwen dan heb je wmb geen idee waar je mee bezig bent.

Stroman. Ik heb zelfs al een opsplitsing/aanpak gegeven.

Ah, het gaat jou om kwantiteit en niet om kwaliteit dus.

En nog een. Daarom staat het woord kwaliteit in de zin erna.

Ik denk dat er wel genoeg mensen zijn die aan unit-tests doen, enkel in veel verschillende vormen en met vele definities van units etc.

Die zin ging over TDD, niet unit tests in het algemeen. Zie de titel van dit topic. Zelfs van unit tests valt de adoptie trouwens tegen. Ik vind dit soort overzichten wel indicatief: http://coverage.livinglogic.de/ Er zijn niet zo heel veel grote open source projecten te vinden met een hoge code coverage, laat staan TDD.

Verder zijn er simpelweg meer manieren van testen dan unit tests. Ook geautomatiseerd.

[farlane]

pedorus schreef op donderdag 09 januari 2014 @ 22:43:
Als velen iets schitterend vinden, het al tijden bestaat, maar maar weinigen het daadwerkelijk doen, dan is dit wellicht een indicatie.

Dat vind ik een zwakke redenering eigenlijk, lang niet alle dingen die goed zijn worden altijd gedaan. ( tandenpoetsen, wc doortrekken, duidelijke requirements vastleggen en noem ze maar op )

[whoami]

pedorus schreef op donderdag 09 januari 2014 @ 22:43:

Nee, het is een opdrachtje. Ik kan toch niet zeggen, laten we de opdracht maar fors versimpelen, want ik wil TDD gebruiken?

Dat zeg ik ook niet. Bij het implementeren van die opdracht kan je uw probleem opsplitsen in deelproblemen, waarbij je voor een deelprobleem (of een stuk van zo'n deelprobleem) een unit-test maakt.

[bertends]

Interessante discussie hier.

Zelf ben ik een groot voorstander van TDD (Als't even kon, en de -niet technische-managers lieten het toe, zou ik constant pair-programmen en ping-pongen tussen test en implementatie), en ik ontwikkel dan ook al enkele jaren altijd via dit principe. Als ik het hier verder over TDD heb verwijs ik overigens naar testing up front.

Wat me opvalt is het gevoel dat TDD langer duurt dan gewoon een implementatie schrijven. Ik ervaar dit helemaal niet zo. Het is wel zo dat het schrijven van de unittesten vaak langer duurt dan de implementatie zelf, maar dit komt dan vooral doordat je tijdens het schrijven van je testen de specificaties zo duidelijk gaat beschrijven dat de gespendeerde tijd bij de implementatie verwaarloosbaar is.
Als je nog moet nadenken over wat je moet implementeren heb je je unittesten niet iteratief opgebouwd en ben je te veel zaken tegelijk aan't doen. Een belangrijk principe in TDD is dat een nieuwe test zo minimaal mogelijk verschilt van een vorige test, maar toch faalt. De aanpassingen aan de implementatie dienen daarna enkel om die ene test te laten werken, en dan begint het spel opnieuw.

Deze manier van werken maakt het programmeerproces overigens voor mij veel leuker, en uiteindelijk is dat de reden waarom ik er ooit überhaupt mee begonnen ben. (Dit is erg subjectief, ik weet het)

Een van de grote voordelen voor mij is dat wanneer je je testen iteratief opbouwt (boundary cases etc etc), dat je unittests je implementatie volledig beschrijven en dus ook kunnen dienen als documentatie. In een applicatie die volledig TDD is ontwikkeld is er geen nood aan technische documentatie. Wil je weten wat een bepaalde class doet, hoef je enkel maar naar de unittests te kijken, en je weet precies hoe deze gaat reageren, inclusief alle boundary cases. Dit is een van de redenen waarom ik de teams waarin ik werk altijd push richting 100% coverage (pushen, ik claim hier niet dat we dit altijd halen).

Ik merk ook dat TDD me verplicht om mijn classes/methods zo klein mogelijk te houden, (anders wordt het schrijven van tests exponentieel moeilijker) wat bijna altijd resulteert in mooiere en leesbare code. Zeker als je werkt met Dependency injection is het heel gemakkelijk om je code van elkaar te scheiden en onafhankelijk van elkaar te testen.

Mooie en leesbare code is in een applicatie waarin meerdere programmeurs werken overigens ontzettend belangrijk. als ik code tegenkom die naar mijn gevoel hier niet aan voldoet zal ik die dan ook altijd proberen te refactoren. Omdat ik weet dat de functionaliteit volledig beschreven en getest is in de unittest kan ik dit ook, ook al weet ik misschien niet precies wat dat stuk code nu precies doet, ik zal altijd weten dat het nog hetzelfde doet dan voor mij refactoring.

Wat je met TDD moeilijker kan testen is integratie met externe systemen (hoe kan je testen of de data die je van een webservice binnenkrijgt wel degelijk de data is die beschreven staat in de documentatie van de api?), UI (al probeer ik zoveel mogelijk javascript ook via TDD te ontwikkelen, tegenwoordig heb je veel testingframeworks voor js), hiervoor bestaan er andere en betere tools. (Ik denk hier aan bijvoorbeeld selenium)

Ook belangrijk om te zeggen is dat zelfs met een coverage van 100% je applicatie niet altijd zal werken zoals verwacht. TDD vervangt daarom ook niet het manuele testen (door dedicated testers), integratie testen, UI testen (met bijv selenium). Voor mij dienen de unittests dus om te bewijzen dat kleine stukken coden werken zoals verwacht, ze dienen zeker niet om te bewijzen dat de applicatie zich gedraagt zoals verwacht.

Maar wat doe je nu met een applicatie waarvoor de specs altijd veranderen, is het geen weggegooid geld om tijd te besteden aan het maken van unittests die funcionaliteit beschrijven die constant veranderd? Ik vind van niet, doordat ik de oorspronkelijke implementatie heb beschreven in mijn tests heb ik er voor gezord dat mijn implementatie duidelijk gedocumenteerd, leesbaar en gescheiden van de rest van mijn applicatie is. De nieuwe functionaliteit inbouwen is nu zo eenvoudig als deze beschrijven in unittests, de implementatie aanpassen en de oude testen die niet meer van toepassing zijn weg te gooien.

Berten

[Verwijderd]

bertends schreef op vrijdag 10 januari 2014 @ 11:39:
Wat je met TDD moeilijker kan testen is integratie met externe systemen (hoe kan je testen of de data die je van een webservice binnenkrijgt wel degelijk de data is die beschreven staat in de documentatie van de api?)

Voor het testen moet je simpelweg de externe systemen niet gebruiken, maar puur hoe je je applicatie reageert op de response hiervan. Je doel is namelijk het testen van je eigen code, externe factoren mogen daar niet in meespelen.

Bij mij test ik het door de class die de response verwerkt testdata te voeren. De makkelijkste manier om dit te doen is door de aanvraag een keer handmatig te doen, al wijkt dit vaak niet af van de welbekende "happy path". Daarnaast zou je dan inderdaad in de documentatie moeten duiken voor wat er gebeurd als het mis gaat. Al maak ik vaak gebruik van webservices die ik zelf geschreven heb, dan is het net iets makkelijker natuurlijk.

[bertends]

Verwijderd schreef op vrijdag 10 januari 2014 @ 11:57:
[...]

Voor het testen moet je simpelweg de externe systemen niet gebruiken, maar puur hoe je je applicatie reageert op de response hiervan. Je doel is namelijk het testen van je eigen code, externe factoren mogen daar niet in meespelen.

Bij mij test ik het door de class die de response verwerkt testdata te voeren. De makkelijkste manier om dit te doen is door de aanvraag een keer handmatig te doen, al wijkt dit vaak niet af van de welbekende "happy path". Daarnaast zou je dan inderdaad in de documentatie moeten duiken voor wat er gebeurd als het mis gaat. Al maak ik vaak gebruik van webservices die ik zelf geschreven heb, dan is het net iets makkelijker natuurlijk.

Natuurlijk maak je testen die de verwachte input van de webservice gebruiken, de integratie met het echte externe systeem is iets wat moeilijker te testen is in een unittest. (Hiervoor heb je dan integratietesten)

[Oljoner]

pedorus schreef op vrijdag 10 januari 2014 @ 00:29:
Ik heb hooguit iets tegen blind unit tests maken.

Waarom zou het maken van tests blind gebeuren bij TDD? Bij TDD maakt het maken van tests gewoon deel uit van je workflow. Je mag het niet zien als 'extra werk', maar gewoon als controle van wat je op dat moment aan het doen bent, om te weten wanneer je klaar bent met een klein deeltje van het probleem. Omdat het deel uitmaakt van de workflow is het niet een tijdrovende bezigheid, maar een manier van werken die imo niet veel trager is (en moest ze trager zijn: dan toch liever slow & steady).

pedorus schreef op vrijdag 10 januari 2014 @ 00:29:
Een nog wat onbelicht aspect in dit draadje is hoe TDD veelal leidt tot een ander design, imo een minder gewenst design.

Als de code voldoet aan goed geschreven testen en wat je schrijft dus ook makkelijk te testen is, dankzij het toepassen van TDD, wat is dan het probleem? Het achterliggend design mag trouwens veranderen zo vaak je wil, zolang maar aan de requirements in de testen voldaan wordt..

pedorus schreef op vrijdag 10 januari 2014 @ 00:29:
Die zin ging over TDD, niet unit tests in het algemeen. Zie de titel van dit topic. Zelfs van unit tests valt de adoptie trouwens tegen.

Iedereen is liever lui dan moe. Ik heb ook een hekel aan het schrijven van testen na het programmeren.
Maar bij TDD vind ik het niet zo erg, dan hoort het bij de workflow, je bent altijd met deelprobleempjes bezig, het voelt in ieder geval niet aan als een belasting.

Gomez12 schreef op donderdag 09 januari 2014 @ 23:30:
Schrijf je een highlevel analyse dan ga je er ook enkel maar highlevel tests op kunnen schrijven (anders wordt het echt zinloos om TDD te gaan doen)

Niet echt akkoord hiermee: in m'n TDD workflow maak ik altijd gebruik van testen en is het niet zinloos. Het verifiëerd dat wat ik doe ook correct is, ook al gaat het om een spike. Vaak zijn deze testen dan wel heel triviaal en houden geen rekening met de corner cases, maar ze maken deel uit van het proces van programmeren...

pedorus schreef op donderdag 09 januari 2014 @ 22:43:
Natuurlijk niet. Maar het gaat erom om de tijd zo efficiënt mogelijk te besteden. Welke methode levert in zo weinig mogelijk tijd zoveel mogelijk (kwaliteits)winst op?

Op lange termijn? Imo zeker TDD.


Nog een recente blogpost die me hier wel relevant lijkt : http://www.javaworld.com/...2022.html#tk.rss_corejava

[pedorus]

bertends schreef op vrijdag 10 januari 2014 @ 11:39:
Wat me opvalt is het gevoel dat TDD langer duurt dan gewoon een implementatie schrijven. Ik ervaar dit helemaal niet zo. Het is wel zo dat het schrijven van de unittesten vaak langer duurt dan de implementatie zelf, maar dit komt dan vooral doordat je tijdens het schrijven van je testen de specificaties zo duidelijk gaat beschrijven dat de gespendeerde tijd bij de implementatie verwaarloosbaar is.

Ik snap hem niet helemaal: het schrijven van de testen duurt langer dan de implementatie zelf, maar toch duurt TDD niet langer? Zonder die testen heb je geen idee hoe je direct de implementatie zou doen?

Oljoner schreef op vrijdag 10 januari 2014 @ 14:04:
maar een manier van werken die imo niet veel trager is

Hoeven we het niet over te hebben, het is gemiddeld gewoon trager, zie het wetenschapelijke onderzoek hierboven.

Als de code voldoet aan goed geschreven testen en wat je schrijft dus ook makkelijk te testen is, dankzij het toepassen van TDD, wat is dan het probleem?

Dat de interface van een met TDD gemaakte library vaak lastiger te gebruiken is voor de eindgebruiker. Een uitleg (herbruikt linkje): Test-driven development is a self-fulfilling prophecy.

Iedereen is liever lui dan moe. Ik heb ook een hekel aan het schrijven van testen na het programmeren.

Ik vind unit tests schrijven achteraf prima, mooi ontspannen en rustig werk, snel resultaat, als je er goed voor betaald wordt is het schitterend toch? Enkel toch, hoe valideer je de antwoorden bij ingewikkeldere output als je nog geen implementatie hebt?

Op lange termijn? Imo zeker TDD.


Nog een recente blogpost die me hier wel relevant lijkt : http://www.javaworld.com/...2022.html#tk.rss_corejava

Mooie meningen, maar helaas geen enkele data die dit ondersteund.

Andere post: Why I don’t use TDD or BDD

Een van de problemen is een gebrek aan examples in concrete situaties. Ik heb in dit draadje al gevraagd naar hoe je TDD nuttig zou gebruiken met een simpele web-applicatie, of wat datacrunching. Verder dan dat je het moet opsplitsen in deelproblemen is het antwoord nog niet gekomen, en dat is met software (bijna) altijd zo. Aantal werkende oplossingen: 0.

farlane schreef op vrijdag 10 januari 2014 @ 10:11:
[...]

Dat vind ik een zwakke redenering eigenlijk, lang niet alle dingen die goed zijn worden altijd gedaan. ( tandenpoetsen, wc doortrekken, duidelijke requirements vastleggen en noem ze maar op )

Ik kan geen goed onderzoek zo vinden, maar ik gok op basis van bijv. het aantal volgers van TDD op stackoverflow.com, dat minder dan 5% van de programmeurs TDD daadwerkelijk toepast. Als zoveel mensen niet zouden tandenpoetsen en/of de wc doortrekken, dan zou je dat direct ruiken op straat.
(Even uitgegaan van de Nederlandse situatie, in sommige landen ruik je dit nml echt..)

[Caelorum]

pedorus schreef op vrijdag 10 januari 2014 @ 14:57:
[...] Enkel toch, hoe valideer je de antwoorden bij ingewikkeldere output als je nog geen implementatie hebt? [...]

Ik blijf dit teruglezen in jouw antwoorden, maar begrijp nog steeds het probleem niet dat jij hier ziet. Als je begint aan die implementatie weet je toch ook al wat je als output wilt hebben? Dan kan je dat toch gewoon in testvorm beschrijven?
Mocht je nog niet weten wat je als output wilt hebben, hoe kan je dan überhaupt een implementatie schrijven?

[bertends]

pedorus schreef op vrijdag 10 januari 2014 @ 14:57:
[...]

Ik snap hem niet helemaal: het schrijven van de testen duurt langer dan de implementatie zelf, maar toch duurt TDD niet langer? Zonder die testen heb je geen idee hoe je direct de implementatie zou doen?

Binnen TDD spendeer ik meer tijd aan het schrijven van mijn testen dan aan de implementatie. Dit omdat je denkproces zich helemaal bevind binnen het schrijven van de testen. Je moet elke keer zo'n enorm klein stukje implementeren dat herleid is naar iets zo simpel dat je er geen werk meer mee hebt.

En nee, dit proces duurt niet langer dan zomaar je implementatie beginnen neer te typen, zelfs niet op korte termijn.

[whoami]

TDD gaat trouwens niet alleen over testen. Het gaat ook over het design van jouw API.
Door eerst de test te schrijven, ga je eigenlijk al gaan nadenken over hoe je jouw class(es) waarmee je het probleem wil gaan oplossen, wil gaan gebruiken.
Je bepaald bij het schrijven van de test al de publieke interface van je class(library). Hierdoor ga je eigenlijk al gaan nadenken over hoe je die classes wil gaan gebruiken, en zal dit dus gaan resulteren in een goede / natuurlijke / leesbare class-interface.

[Oljoner]

pedorus schreef op vrijdag 10 januari 2014 @ 14:57:
Hoeven we het niet over te hebben, het is gemiddeld gewoon trager, zie het wetenschapelijke onderzoek hierboven.

Het is inderdaad geen belangrijk punt, maar voor mezelf is het snelheidsverschil verwaarloosbaar.
Uit de studie waar je naar refereert, blijkt dit ook:

"The results indicate that, in general, TDD has a small positive effect on quality but little to no discernible effect on productivity."

Hoewel;

"However, subgroup analysis has found both the quality improvement and the productivity drop to be much larger in industrial studies in comparison with academic studies."

Om deze claim waar te maken, zouden ze wat oorzaken moeten opsommen (vb geen ervaring met testen, niet graag test & het per express trager doen, de workflow die de personen in kwestie niet lag, of toch echt het coden van de unit testen die enorm lang duurde..?)

Over de kwaliteit van de uiteindelijke code van de "industrial studies" kan men in bovenstaande studie geen sluitend antwoord op geven:

"however, no conclusion could be derived regarding the industrial studies due to the lack of data."

Hoewel het voor de academische wel het geval was:

"A larger improvement in quality was also found in the academic studies when the difference in test effort is substantial"

pedorus schreef op vrijdag 10 januari 2014 @ 14:57:
Dat de interface van een met TDD gemaakte library vaak lastiger te gebruiken is voor de eindgebruiker. Een uitleg (herbruikt linkje): Test-driven development is a self-fulfilling prophecy.

Uiteraard is een ervaren developer beter en sneller dan een onervaren developer. Moest dat anders zijn dankzij TDD zou de it wereld op z'n kop staan. 90% van dat artikel lijkt me onzin, buiten het punt dat hij maakt van van leaky interfaces:

Leaky interfaces. The OO law of encapsulation has to be broken to expose internals that would never otherwise need to be visible outside of a class or project.

Als antwoord daarop ben ik van volgende mening: http://stackoverflow.com/a/34586

Ik vind unit tests schrijven achteraf prima, mooi ontspannen en rustig werk, snel resultaat, als je er goed voor betaald wordt is het schitterend toch?

En dan is TDD toch tijdverspilling?

Andere post: Why I don’t use TDD or BDD

Uit die link:

Unit tests=more code. This is just a personal belief; I think the less code, the better. I’m a minimalist.

Tja, als je van die mening bent heb je imo nooit verantwoordlijkheid gehad voor software die langere tijd in productie draait en waar toch nog regelmatig veranderingen aan moeten worden doorgevoerd...
Geen probleem uiteraard, maar dan lijkt het me kort door de bocht om de voordelen van TDD in twijfel te trekken.

Een van de problemen is een gebrek aan examples in concrete situaties. Ik heb in dit draadje al gevraagd naar hoe je TDD nuttig zou gebruiken met een simpele web-applicatie, of wat datacrunching.

Zoek eens op youtube naar "TDD session". vb: http://www.youtube.com/watch?v=IfYHrARvTxo

Ik kan geen goed onderzoek zo vinden, maar ik gok op basis van bijv. het aantal volgers van TDD op stackoverflow.com, dat minder dan 5% van de programmeurs TDD daadwerkelijk toepast.

Wie maalt daar om? Als een techniek je goed ligt en ze levert je veel voordelen op en slechts weinig nadelen, waarom zou je ze dan niet gebruiken? Omdat maar 1% van stackoverflow het toepast?

[m-m]

Interessant topic. Zelf werk ik niet met TDD (ik zou het graag leren, maar zelfstandig en binnen mijn huidige baan is dat wat lastig) maar wat voor mij fijn lijkt is min of meer de garantie dat voor alles tests zijn zodat ik naar hartelust kan refactoren/veranderen en het direct weet als mijn wijziging onvoorzien een andere functionaliteit breekt wat nu misschien pas in productie zou opvallen. Een ander voordeel is dat het wat, vanwege het moeten kunnen testen, kortere methods afdwingt die niet te veel in één keer proberen te doen. Dit is iets waar ik mij in onze huidige codebase mateloos aan erger, ik probeer er zelf op te letten (lukt lang niet altijd) maar ook niet elke collega ziet er de noodzaak van in. Als iedereen met TDD zou werken, zou dat niet spelen. Beide zaken zouden de onderhoudbaarheid flink ten goede komen.

Natuurlijk zie ik ook wel nadelen. Het vereist een boel discipline, het kost (zeker in het begin heel veel) meer tijd en je moet (denk ik) uitkijken dat het niet naar een extreem punt doorschiet maar ook niet te veel relaxt tot aan het punt dat het niet zinnig meer is en je er een vals gevoel van veiligheid van krijgt. Wat dat betreft zou ik wel gewoon een tijdje willen samenwerken met iemand die al enkele jaren ervaring heeft met die manier van werken.

[Down]

Interessant topic. Wat ik me vooral afvraag is hoe mensen in verschillende functies tegen TDD aankijken. Een tijdje terug ben ik begonnen aan een nieuwe baan (er prijkt nu lead developer op mijn visitekaartje ). De afgelopen jaren was ik steevast simpelweg 'software engineer' wat voornamelijk bestond uit code kloppen (en vooruit, hier en daar wat documentatie). Gedurende die tijd was ik best veel bezig met allerlei zaken die te maken hadden met kwaliteit van code (TDD, unit testing, peer reviews etc).

Echter, in mijn nieuwe functie word ik ook afgerekend op de commerciële waarde van functionaliteit die ik met mijn team produceer. De keuze voor de quick fix is nu ineens een stuk aantrekkelijker geworden. En dat terwijl ik vroeger altijd best wel de schurft had aan de manager of lead developer die weer aan kwam zetten met de zoveelste quick fix. Dit betekent overigens niet dat ik me niet bekommer om de kwaliteit van de code, echter is het perspectief enigszins veranderd.

[pedorus]

Caelorum schreef op vrijdag 10 januari 2014 @ 15:05:
Mocht je nog niet weten wat je als output wilt hebben, hoe kan je dan überhaupt een implementatie schrijven?

Het kost mij redelijk wat werk om handmatig een antwoord te berekenen/in te vullen als dat antwoord wat ingewikkelder is. Daarvoor schrijf ik nu net een programma... Verifiëren is veelal makkelijker dan maken. Een test maken die niet het hele antwoord goed verifieert kan ook wel, maar dat is een beetje gevaarlijk natuurlijk... Dat geeft vooral code coverage, en geen goede test.

De meeste TDD examples gaan allemaal uit van simpele, handmatig te berekenen antwoorden (krijgen klanten van type x nu echt y% korting?). Tsja, dan heb je dat niet.

whoami schreef op vrijdag 10 januari 2014 @ 15:55:
en zal dit dus gaan resulteren in een goede / natuurlijke / leesbare class-interface.

Dus oneens met Test-driven development is a self-fulfilling prophecy?

Oljoner schreef op vrijdag 10 januari 2014 @ 18:30:
Uit de studie waar je naar refereert, blijkt dit ook:

Ik refereerde naar een stuk of 3 studies hierboven, en ik weet niet welke je hebt gepakt. In zijn algemeenheid zou ik liever kijken naar industriële data, ipv academische exercities. Geen van de overzichtsstudies vond aantoonbare verhoogde productiviteit op langere termijn, wel op korte termijn mogelijk betere kwaliteit volgens sommige maatstaven ten koste van meer benodigde arbeidsuren.

Als antwoord daarop ben ik van volgende mening: http://stackoverflow.com/a/34586

Interessant, zo'n antwoord met 100+ votes met een comment met disagree eronder met een stuk meer votes. Zie je niet vaak.

En dan is TDD toch tijdverspilling?

Veel spelletjes spelen onder werktijd is ook niet beroerd. Dat heeft enkel weinig met de productiviteit van doen.

Uit die link:

[...]

Tja, als je van die mening bent heb je imo nooit verantwoordlijkheid gehad voor software die langere tijd in productie draait en waar toch nog regelmatig veranderingen aan moeten worden doorgevoerd...
Geen probleem uiteraard, maar dan lijkt het me kort door de bocht om de voordelen van TDD in twijfel te trekken.

Je hebt succesvol het zwakste argument uit die post aangevallen.

Zoek eens op youtube naar "TDD session". vb: http://www.youtube.com/watch?v=IfYHrARvTxo

Dat is een filmpje zonder uitleg/geluid en ik vind het maar een vreemd project. Niet echt die simpele webapplicatie of datacruncher waar ik naar op zoek was. Sommige posts op dit forum of op SO bevatten meer functionaliteit dan dit hele project. Het lijkt erop dat er meer commits zijn (201) dan regels code die iets doen (dus afgezien van documentatie/unit tests/e.d.).

Hit 2 is misschien beter, maar dat is ook een demoproject en als ik er door heen zap en ik zie het gebrek aan verstand van c# programmeren van die gasten (bijv. enumwaarde met null vergelijken) geeft dat te denken over hun verstand van de rest.

[Waster]

TDD is een geloof. Het geloof dat je perfecte controle kan hebben over je programmeer project: de tijd, het aantal bugs, de kwaliteit van de code. Dat is een illusie. Het kost wel veel tijd. Maar als je dat er voor over hebt om een gevoel van controle te hebben, moet je dat vooral doen.

Unittests zijn met name geschikt om geïsoleerde stukjes business logica te testen die if-branches bevatten.
Een GUI ga je niet unit-testen, maar daarvoor heb je een volledige integratie of gebruikers test. Ik ben nu met een project bezig dat clusterverdelingen maakt in een topologisch netwerk. Dit is Artificial intelligence-achtig en de werking is alleen te testen op het allerhoogste niveau door de clusters te visualiseren. Veel modules hangen aan elkaar en de functionaliteit kun je niet van te voren definiëren. Dat weet je pas achteraf of het werkt. Integraties kun je ook niet unittesten. Als het werkt dan werkt het, als het niet werkt dan fix je het. Er is geen logica daar om te testen. Ik heb ook meegemaakt dat mensen zo op dreef waren met unittesten dat ze alles aan het mocken, stubben en faken waren dat het enige wat overbleef was het unittest framework dat ze aan het testen waren

Ik ben wel een heel groot voorstander van om alles te abstraheren en in modules te plaatsen, de Data/Model en de View te scheiden. De modules die testbaar zijn, kun je dan tenminste ook testen. Overigens kun je net zo goed naderhand testen. Naderhand een unittest schrijven als je een bug hebt ontdekt is toch handiger dan op voorhand voor honderden functies testen op null values en er dan achter komen dat er alsnog die ene bug in zit waar je een unittest voor moet schrijven.