Tag testen
Goede code is geteste code
Goede code is geteste code. Het is testbare code, zeker – en er zijn tests die het bewijzen. Als er geen tests zijn, dan is het geen goede code. – De vraag hier is natuurlijk: wat is goede code, wat betekent “goede code”? Is het code die doet wat het moet doen? Die netjes gestructureerd is? Die er goed uitziet?
Altijd up to date documentatie met maximaal descriptieve tests
Door extra aandacht te besteden aan de scope en leesbaarheid van je tests, kun je deze transformeren van eenvoudig validatiemechanisme naar gezaghebbende bron van informatie voor ontwikkelaars. Met maximaal descriptieve tests is je documentatie altijd up to date.
Technieken vs trucjes
Een goede programmeur is een luie programmeur – dat is een bekende wijsheid in softwareontwikkelland. Want: een luie programmeur automatiseert oninteressante, repetitieve taken, en creëert op die manier de ruimte om zich bezig te houden met interessante, afwisselende taken. – Althans, dat is één opvatting van wat het betekent om een luie programmeur te zijn. Maar er zijn nog veel meer manieren om lui te zijn. Vandaag wil ik het hebben over zo’n andere manier. Vandaag wil ik het hebben over de wens, behoefte of neiging om een techniek te reduceren tot een trucje.
Testen: Een filosofisch retrospectief
Eerst programmeren de programmeurs, dan testen de testers: het komt niet vaak voor dat zo’n voor de hand liggend idee zoveel misvattingen herbergt. Welk aannames liggen ten grondslag aan dat idee? En wat gebeurt er wanneer we die aannames kritisch tegen het licht houden?
Waarom testen testers?
Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?
Blog #250!
Jeetje, ik blog alweer een tijdje! Er zijn 767 dagen voorbij gegaan sinds ik mijn honderdste blog schreef. Dus: feest! Vandaag blik ik terug op de laatste 150 blogs.
Waarom testers code moeten reviewen
Het klinkt als een natuurwet: programmeurs programmeren en testers testen. Maar die taakverdeling leidt tot inefficiënte werkprocessen met lange feedbackcycli. Om kwaliteit én snelheid te kunnen borgen, moet geautomatiseerd testen een tweede natuur worden voor het hele ontwikkelteam. Testers spelen hier een essentiële rol in.
Test-Driven Development en YAGNI
Vaak werkt het zo: tests maken x mogelijk, Test-Driven Development (TDD) tilt x naar een volgend niveau. Welnu, het idee van YAGNI – You Ain’t Gonna Need It – veronderstelt tests. TDD tilt het naar een volgend niveau. Tests faciliteren YAGNI, TDD radicaliseert het.
YAGNI veronderstelt tests
Er zijn twee soorten ontwikkelaars: ontwikkelaars die roepen: “You ain’t gonna need it”, en ontwikkelaars die mompelen: “Ja ja, dat roep je wel, maar ik bouw het voor de zekerheid toch maar in.” Ik behoor tot het eerste kamp; enkele van mijn collega’s tot het tweede. – Maar waarom?
Moet testen een onderdeel van een tutorial zijn?
Onlangs las ik Building Web APIs with ASP.NET Core van Valerio De Sanctis – niet omdat het ontwikkelen van Web API’s in ASP.NET Core onontgonnen terrein voor me was, maar omdat het nooit kwaad kan om op zoek te gaan naar gaten in je kennis, ook als je een techniek al tijden gebruikt. Bovendien had ik het boek in een vroege fase gereviewd, en ik was benieuwd wat er uiteindelijk van was geworden.