Een tip voor testers
Elke softwareontwikkelaar weet dat hij zijn werk goed moet testen. Waarom glippen de meest voor de hand liggende bugs er dan toch doorheen? Omdat testen bij testers is belegd. Dat klinkt voor programmeurs verleidelijk efficiënt: waarom tijd besteden aan het schrijven van tests als iemand het werk toch nog naloopt? Deze taakverdeling nodigt uit tot lagere codekwaliteit en legt de pijn daarvan bij testers.
Behoefte aan een testlane
Als we met z’n allen met één ding bezig zijn, dan is onmiddellijk, voor iedereen, zichtbaar wat er al getest is en wat niet. Een testlane is een lapmiddel voor het eigenlijke probleem: dat we onvoldoende samenwerken. Daardoor weten we niet wie wat al heeft gedaan. Dáárom heb je behoefte aan een middel om daar inzicht in te verkrijgen.
Bezwaren tegen continuous deployment
Continuous deployment is: elke commit gaat meteen naar productie. Er is geen testomgeving, er is geen acceptatieomgeving; er zijn geen lang levende branches behalve de main branch, en die is gelijk met productie. – Waanzin! wil je roepen, dat kan nooit werken! – Oké. Waarom niet?
Uitrollen, vlak voor de demo
“Ik vind dat we niet meer uit moeten rollen vlak voor een demo,” zei een collega, “dat vond ik nogal spannend.” Liever had hij zichzelf nog wat extra tijd gegeven om zekerheid te krijgen dat de wijziging niet onbedoeld dingen stuk had gemaakt. Ik begrijp het sentiment van waaruit deze opmerking ontspringt. Maar het is in mijn beleving de verkeerde diagnose van de situatie.
Entity services en het contextprincipe
Een domein bestaat uit een aantal entiteiten. Voor een webwinkel zijn dat dingen als product, winkelwagentje en bestelling. Zulke entiteiten verwachten we terug te vinden in onze code: Product, ShoppingCart en Order. In veel codebases vinden we, naast deze entiteiten, corresponderende objecten: services. De logica rondom een product wordt afgehandeld in de ProductService, die van een winkelwagentje in een ShoppingCartService – en waar je de logica voor een bestelling kunt vinden, kun je vast wel raden. Het gedachteloos introduceren van dit soort entity services is me een doorn in het oog.
TDD en de testpiramide
Ik ruimde een boekenkast in op het werk, toen een collega me vroeg of ik wist hoe je een call naar een keyed service uit de IServiceProvider mockt. Nee, niet direct, zei ik. Maar waarom zou je dat überhaupt willen? Vanaf daar ontspon er een gesprek over Test-Driven Development, het ontwerp van code en de verschillende delen van de testpiramide.
Moeten refactorings ook gereviewd worden?
Niet elke codewijziging is gelijk. Sommige wijzigingen veranderen het gedrag van een systeem. Andere wijzigingen, refactorings, veranderen alleen de structuur en laten het gedrag gelijk. Zoals de meeste teams hun werk inrichten, met pull requests en formele code reviews, wordt elke wijziging door twee paar ogen bekeken. Maar is dat wel nodig?
TDD is een vraaggesprek
Plato’s dialogen zijn toegankelijk, inzichtelijk en vaak ook ontzettend grappig. Eén van de redenen waarom ze vandaag de dag nog zo goed leesbaar zijn, zit ’m in die dialoogvorm. Het spel van vraag en antwoord geeft leven aan Plato’s filosofische onderzoekingen, het voorkomt dat het een droge uiteenzetting wordt van argumenten en conclusies. Omdat ik nu eenmaal een beroepsdeformatie heb, kon ik het onder het lezen niet nalaten aan Test-Driven Development te denken. Want ook TDD is een soort van vraaggesprek, en ook TDD geeft leven aan het oplossen van een programmeertaak.