Tag testen
Agile en Test-Driven Development
De meeste ontwikkelaars (waaronder ondergetekende!) schrijven als volgt code. Ze bekijken de specificaties en beginnen vervolgens te klungelen. Dat duurt een tijd, totdat ze iets hebben wat werkt. Of dat zo is, verifiëren ze middels handmatige tests. Pas als de code werkt als bedoeld, schrijft men - als het goed is! - een reeks geautomatiseerde tests. Het is een hardnekkig misverstand dat TDD deze praktijk van software schrijven omdraait: eerst de geautomatiseerde tests (meervoud!) schrijven, en dan pas de productiecode. De werkelijkheid ligt wat genuanceerder.
Blog #100!
Een minimijlpaal: dit is mijn honderste blog! In krap een jaar heb ik 80.168 woorden over softwareontwikkeling geschreven, gecategoriseerd onder 112 tags. Het leek me een mooi moment voor een knap staaltje navelstaren, met hier en daar een snuifje zelfpijperij. Bij dezen: tien blogs waar ik met iets van plezier op terugkijk.
De leercurve van Angulartests beklimmen - deel 4
Wat is de kern van ons onderhoudprobleem? Codeduplicatie - of liever: de duplicatie van informatie. Het opzetten van een bepaalde service en haar afhankelijkheden gebeurt voor elke (reeks) test(en) handmatig in de beforeEach-methode. Als dezelfde afhankelijkheid in twee verschillende reeks testen voorkomt, moet de ontwikkelaar deze twee keer uitschrijven. Maar is dat nu echt nodig?
De leercurve van Angulartests beklimmen - deel 3
Hoe onderhoudbaar was onze testopzet? Onze services verwachtte niet één afhankelijkheid, maar wel vijf of zes of zeven - en soms zelfs meer. En die afhankelijkheden verwachtten op hun beurt ook weer vijf, zes, zeven afhankelijkheden. Het was niet ondenkbaar dat een ontwikkelaar langer bezig zou zijn met het opzetten van al die afhankelijkheden om zijn test te laten compileren, dan het daadwerkelijk verifiëren van het gedrag van het stukje code waar hij in was geïnteresseerd.
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.
Hoe Nooglers testen de norm maakten
Google greep haar snelle groei aan als kans. In plaats van zich te focussen op hun bestaande werknemersbestand, richtte het management ze zich op nieuwe medewerkers. Ze gaven deze nieuwe Googlers, liefkozend Nooglers genoemd, bij binnenkomst allemaal hetzelfde praatje over testen en het belang ervan. Ze gebruikten de Nooglers, buiten hun weten om, als Trojaans paard om een cultuurwijziging te bewerkstelligen.
Is onze performancetest mislukt?
Het doel van de performancetest was niet om aan te tonen dat onze applicatie de load aankon. Het doel was om erachter te komen of onze applicatie de load aankon. Nu weten we het antwoord: nee. Men zegt niet voor niets: meten is weten, en niet: meten is slagen.
Stap voor stap software testen
Software testen is een vak apart. Veel ontwikkelaars hebben wel een schetsmatige notie van hoe een goede test eruit dient te zien, maar ontberen een gedegen theoretisch fundament. Zulke ontwikkelaars zouden er goed aan doen om Essentials of Software Testing van Ralf Bierig, Stephen Brown, Edgar Galván en Joe Timoney te lezen.