Wat is een unit?
Een tijd geleden presenteerde ik enkele ideeën over testen aan mijn collega’s. Toen ik aankwam bij het gedeelte waarin ik stelde je het best via de voordeur kunt testen, stelde een collega apodictisch: “Een unittest test een openbare method op een class. Elke afhankelijkheid op die class moet je mocken.” Dat is een manier om er naar te kijken, zeker. Het is de zogenaamde mockist strategie, ook wel bekend als de Londense school van unittesten. De vraag waar ik me op wil richten is: waar komt de aantrekkingskracht van deze strategie dan vandaan? Ik geloof dat deze voortkomt een bepaalde interpretatie van wat een unittest is of moet zijn. Meer specifiek: wat de unit in unittest is of moet zijn.
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
Waarom zijn zoveel programmeurs bètanerds?
Als filosoof kan ik een titel als How do our ideas about coding affect the software we create? natuurlijk moeilijk weerstaan - en ik heb dan ook met veel plezier naar het gelijknamige praatje van Christin Gorman gekeken. Gorman begint vanuit een probleem: de softwareontwikkelpopulatie (3x woordwaarde) is weinig divers. Ze bestaat, gechargeerd gezegd, voor het grootste gedeelte uit nerds met interesses in de hoek van de bètawetenschappen. Hoe komt dat?
Het Single-Responsiblity Principe en mijn keukenkastjes
Ik vind er wat van dat ik twee verschillende keukenkastjes moet openen voor iets wat in feite één handeling is. Ga maar na: wanneer pak je een koffiekopje? Als je koffie gaat zetten. En wanneer pak je een koffiepad? Als je koffie gaat zetten. Het pakken van een koffiekop gaat altijd gepaard met het pakken van een koffiepad. Het is een atomaire handeling.
De fix die productie om zeep hielp
“De fix staat op productie,” meldden we trots. “Het bleek te liggen aan wat validatielogica die in dit specifieke scenario wat te streng bleek - enfin, een technisch verhaal, dat hoef je niet te weten. Het enige wat je hoeft te weten is: we hebben weer eens geweldig werk geleverd, bedankjes worden gewaardeerd maar zijn niet noodzakelijk.” En we leefden nog lang en gelukkig. Een halfuur lang. Want toen kregen we een berichtje: “Help! Ik kan nu geen enkel item meer inzien!”
Hoe ik hopelijk (nóg?) betere presentaties geef
Laatst verzorgde ik een Developer Meet-up over het schrijven van (nóg betere) unittests. Volgens mij ging de presentatie heel aardig (jeej!), maar ik heb het meest geprofiteerd van alles wat er niet goed aan ging. Liever gezegd: ik heb het meest geprofiteerd van de woorden die mij die ochtend waren aangereikt om te kunnen duiden waarom sommige dingen beter konden. Want toevallig volgde ik die ochtend een (online) masterclass online presenteren van Serge van Rooij - waar ik veel meer aantekeningen bij maakte dan ik op voorhand verwacht had. En omdat deze blog nu eenmaal het product is van een verwoede kennishamsteraar, deel ik met alle liefde de inzichten die ik graag nét een weekje eerder had willen weten.
De ForEach aan het eind van je functieketen
Het idee dat een functie altijd een waarde retourneert, is erg krachtig. Zo zorgt het ervoor dat je eenvoudige tests voor je functies kunt schrijven. Helaas is de werkelijkheid weerbarstig, en is het retourneren van een waarde niet altijd voldoende. Soms moet code neveneffecten bewerkstelligen. Denk bijvoorbeeld aan het wegschrijven van bepaalde data naar een tekst- of zipbestand. Het resultaat van zulke code kan niet in een teruggegeven waarde worden gevangen.
Horizontale en verticale architectuur
Als we onze applicatie verticaal op zouden hakken, dan zouden we af kunnen komen van onze ongemakkelijke naamgevingsconventies. Elke slice zou zijn eigen project krijgen, en elk project zijn eigen model. Of het nu over items in isolatie gaat, of items in een toets, of items in een itembank - we zouden in de code altijd over Item kunnen spreken - net als de gebruiker.
Betere documentatie door PR-templates
Elk pull request biedt een gelegenheid om documentatie te schrijven. Toen ik dat punt een tijd geleden inbracht tijdens het tweewekelijkse Alignment-overleg van mijn team, viel mij tot mijn verbazing een hoop instemmend geknik ten deel. Hoe plezierig dat ook was, eerlijk gezegd verwachtte ik niet per se dat mijn pleidooi veel navolg zou vinden. Programmeurs en documentatie is en blijft nu eenmaal een moeilijk huwelijk. Maar mijn team verraste me positief.
Wat is een functor?
Wat is een functor, vraag je? Lang verhaal kort: functors zijn typen die een Map-functie implementeren. Wat is een Map-functie, vraag je? Lang verhaal kort: ken je LINQ? - heb je wel eens Select gebruikt? - nou, dat dus. Maar misschien loont het zich er nét iets langer bij stil te staan.