Vejen til software-success: Drop test og skriv funktioner på fem linjer

På min arbejdsplads har vi for nogle år siden lagt en stor tids-investering i at introducere tests. Det gør at vi i forhold til tidligere har forøget vores udviklingshastighed samtidig med at vi har fået langt mere stabile systemer. Der er heldigvis steder hvor folk har tests.

Med introduktionen af tests er det samtidig blevet lettere at onboarde nye medarbejdere fordi man nu ikke længere behøver at frygte at noget går i stykker første gang man rører et stykke kode man ikke har 100% overblik over.

Der findes helt sikkert scenarier hvor tests ikke er stedet at starte, og det er vel i et eller andet omfang det artiklen beskriver, men mere eller mindre helt at afskrive værdien af tests fordi ingen laver dem alligevel er en fejl i min optik.

Så snart der er flere tilstande i et system, dvs. opførsel i et system, og der ikke er tale om "simple" datalogiske funktioner, så vil jeg i den grad våge at påstå, at man har behov for at unit-teste (og evt. behov for at integrations-teste) - og pssst man har osse brug for at teste "simple" datalogiske funktioner. ;-) Mennesker plejer at være ekstremt dårlige til at begribe et helt system og dets mange tilstande. Så hvis man ikke har aftestning, der beskriver forventet opførsel set ud fra fx use cases/ansvarsområder, jamen så er du på herrens mark, når to forskellige mennesker skal komme med deres bud på, hvordan systemet virker på kode-niveau og evt. logiske "mellemlag" - fx service til service. Jeg synes man glemmer at forholde sig til, at der er forskellige skoler for fx at teste/unit-teste. Altså der er dem, der skriver tests først, og dem der skriver tests efterfølgende. Så man kunne jo evt. vælge at bruge at skrive tests til sidst eller undervejs i artiklens eksempler. Man kunne osse overveje at prototype sig, og når man har noget der mocker tilpas (fx i forhold til det gamle system, men skrevet fx i nyt sprog/ny kode), til det man ønsker, så kan man overveje at skrive test, der beskriver systemets forventede opførsel. Men det afhænger af kultur og personlighed, hvad man lægger sig op ad. Findes der nogen eksakt videnskab, der beviser, hvad den rette fremgangsmåde er? Hvis ja, lad os høre om det, og hvis nej, så kan "min" holdning være ligeså god som "din", men jeg lytter gerne, hvis argumenter mht. noget "nyt og fancy" er godt. :-) Tester man ikke koden, inden den sendes til kunden og slutbrugeren, så ender man med, at det er dem, der sidder med problemet. Det er billigst at rette fejlene tættest på problemet og så tidligt som muligt. Jeg savner i artiklen, om vi primært snakker brugerflade, eller snakker vi forretningslogik, eller hvor er vi henne?