Tag clean code
De leercurve van Angulartests beklimmen - deel 2
In een vorige blog beschreef ik de keuze van mijn team om de front end van onze Angular-applicatie te testen via end to end-tests - en waarom we daar uiteindelijk op terugkwamen. Nu we besloten hadden inderdaad te willen (nee, moeten) unit testen, doemde er een nieuwe keuze op in de beslisboom: gaan we ons in het zweet werken om Angulars steile leercurve te beklimmen, of bekijken we of er een manier is waarop we het testen voor ons kunnen vergemakkelijken?
Hoe droog wil je je test hebben?
Ik heb in het verleden over droger tests geschreven, want ik ben een softwareontwikkelaar en wij herhalen onszelf niet graag. En precies daarom ga ik het nóg een keer over droger tests hebben - of liever: minder droge tests. Want, anders dan je als naïeve ontwikkelaar zou verwachten, gelden er voor productiecode en testcode andere regels wat betreft de mate waarin herhaling tolerabel of zelfs wenselijk is.
De leercurve van Angulartests beklimmen - deel 1
Niet lang nadat we Angular als front end-framework besloten te gebruiken, maakten we de keuze de unit tests te laten voor wat het was. We waren heus wel overtuigd van het belang ervan, dat was het probleem niet, maar de stijle leercurve van Angulars tests verleidde ons daar niet naar te handelen. Toch lieten we het testen van de front end niet helemaal schieten. Onze tester had zich verdiept in end to end testframework Selenium, en het team wilde graag geloven dat dit een acceptabel alternatief was voor het schrijven van front end tests. Maar uiteindelijk dwong de werkelijkheid ons toch die beslissing te herzien.
Twee sonnetten over software ontwikkelen
Stakeholder, u stijgt pas echt in achting / Als u - prijs de Heer voor dit geluk! - / Inziet wanneer niet de code de bug / Herbergt, maar uw eigen verwachting.
Zonde om weg te gooien?
Laatst kwam ik tijdens het refactoren een stuk code tegen dat alleen maar werd gebruikt in unittests. Dat maakt me erg verdrietig, en om dat verdriet niet te hoeven voelen, donderde ik dat stuk code weg zodat ik er nooit meer naar om zou hoeven kijken. Een collega van me maakte bezwaar toen hij mijn pull request bekeek. En, eerlijk is eerlijk, niet helemaal onterecht. Er was veel moeite in deze feature gestopt, zei hij. Was het niet zonde om deze code zonder omzien te verwijderen?
Goede code documenteert zichzelf (niet)
Uit de code valt niet af te leiden wat de specificaties zouden moeten zijn. Om met David Hume (1711-1776) te spreken: een ought valt niet af te leiden uit een is. Wie zegt dat goede code zichzelf documenteert, maakt zich schuldig aan de naturalistische dwaling. En toch zit er een kern van waarheid in het idee dat goede code zichzelf documenteert.
Waarheid boven schoonheid
Anders dan Aristoteles, Kant en Wittgenstein, hebben we als softwareontwikkelaars de luxe ons niet bezig te hoeven houden met de metafysische grondstructuur van de werkelijkheid. Dat vereenvoudigt het ontwikkelen van onze applicaties aanzienlijk. Maar dezelfde hang naar schoonheid die ik bij filosofen zo amusant vind, duikt bij tijden ongemerkt in mijn eigen werk op.
Meer dan een zwarte doos
De basis van een programmeren kost je misschien een weekendje, maar een goed programma leren schrijven, dat is een proces van jaren. Waarom? Het besef dat een goed programma meer is dan een werkend programma, daalt pas na veel vallen en opstaan in. Studenten en beginnend programmeurs die meer uit hun strubbelingen willen halen, doen er daarom goed aan Perdita Stevens' How to Write Good Programs aandachtig te lezen.
Droger tests met factory methods
Ga eens voor jezelf na: hoe instantieer je objecten in je unit tests? Introduceer je veel codeduplicatie over tests heen? Wat zegt dit over je houding tegenover testcode? Is die houding hetzelfde als die tegenover productiecode?
Vijf haiku's over software ontwikkelen
schoonheid zit in iets / zo klein als een method die / precies één ding doet