Testen, het favoriete werk van de programmeur

Om mezelf toch weer eens te overtuigen ben ik naar de sessie Flextesting geweest van Steve McConnel en eerlijk is eerlijk. Na deze presentatie had ik zelfs zin om te gaan testen (al zakt dat gevoel wel weer). Met bezieling en passie ging Steve in een rotgang door alle 1000 redenen heen waarom developement en test altijd paralel moeten lopen. Per jaar gaat er $ 80 miljard op aan het oplossen van bugs. De helft komt bij de consument terecht en de andere helft bij de developer. Wat nog erger is, is dat een programmeur 80% van zijn werktijd doorbrengt met bugfixing. Een requirementbug oplossen na oplevering kost 10 tot 100 keer zoveel dan wanneer de bug tijdens developement was ontdekt. Een fout in de architectuur kost 25 tot 100 keer zoveel. Het is verleidelijk om het testen over te laten aan mensen want dat is in het begin goedkoper. Een developer die allerlei unittesten maakt kost immers veel geld. Naarmate een project groeit, groeit ook het aantal testen en worden er testen overgeslagen of komen ze pas na zoveel tijd weer aan bod dat men niet heeft ontdekt dat een kleine aanpassing links toch invloed heeft gehad op een stukje code rechts. Geautomatiseerd testen kan dit voorkomen maar zoals aangegeven kost dit in het begin meer. Gelukkig verdien je dat op den duur terug. Is dat een 100% garantie? Nee, want de developer blijft verantwoordelijk welk deel er wel en niet getest wordt. (code coverage) Om het toch zo goed mogelijk te doen start met voor iedere methode of functie een unittest te schrijven. Deze worden gebundeld in een integratie test waar dus eigenlijk de samenwerking tussen de units worden getest. Tot slot is er dan nog de functionele test. Ook voor flex zijn er meerdere hulpmiddelen: Flexunit, Fluint, Funit (nu nog te licht maar een tip voor de toekomst), Visualflexunit, Funfx, en Flexmonkey