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

Plus12. oktober 2022 kl. 04:002
Christian Clausen
Illustration: Tania Andersen.
Det er mennesker, man skal have i tankerne, når der er gået rod i en større kodebase. Compileren, stærke typer og ensemble-programmering er vejen frem, mener dansk forfatter og datalog.
Artiklen er ældre end 30 dage

I den virkelige verden er der ikke tid til at skrive tests, og slet ikke, hvis man skal rydde op i en stor bunke gammel kode, som er blevet svær at vedligeholde.

Sådan lyder erfaringen, som Christian Clausen har gjort sig den. Han er forfatter til bogen Five Lines of Code om samme emne, og datalog fra Aarhus Universitet.

I forrige uge gav han et indlæg om emnet på Goto Cph-konferencen i København.

close
Gratis adgang i 30 dage
Tegn et gratis prøveabonnement og få adgang til alt PLUS-indhold på Version2 og Ingeniøren, helt uden binding eller betalingsoplysninger.

Alternativt kan du købe et abonnement.
remove_circle
remove_circle
Har du allerede et PLUS-abonnement eller klip?
Tak !
Vi har sendt en kvitteringsmail til .
Du bliver viderestillet til artiklen om få sekunder.
Dit medlemskab giver adgang
Som medlem af IDA har du gratis adgang til PLUS-indhold, som en del af dit medlemskab. Fortsæt med MitIDA for at aktivere din adgang til indholdet.
Oplever du problemer med login, så skriv til os på websupport@ing.dk
Abonnementsfordele
vpn_key
Fuld adgang til Version2 og Ingeniøren
Fuld digital adgang til PLUS-indhold på Version2 og Ingeniøren, tilgængeligt på din computer, tablet og mobil.
drafts
Kuraterede nyhedsbreve
Det seneste nye fra branchen, leveret til din indbakke.
Adgang til andre medier
Hver måned får du 6 klip, som kan bruges til permanent at låse op for indhold på vores andre medier.
thumb_up
Adgang til debatten
Deltag i debatten med andre kloge læsere.
2 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
14. oktober 2022 kl. 14:11

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.

1
12. oktober 2022 kl. 22:35

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?