Unittest er ikke længere på mode

Unittest, de adrætte metodikkers yngling, er måske ikke længere et så varmt emne som det har været. Det er er der flere ting, der peger på, mener it-journalisten Andrew Binstock.

Unittest, som har fået et løft i opmærksomhed ved at være en kerne-del af de adrætte metodikker, i særdeleshed Extreme Programming (XP), er måske ikke så "hot" som det har været.

Det mener i hvert fald Andrew Binstock, som er journalist ved SDTimes og Infoworld, og flerårig dommer ved Jolt-prisudrækkelsen.

I et nyligt indlæg på sin blog sætter Binstock spørgsmålstegn ved populariteten af unittest. Han ser en række tegn i sol og måne på, at test-teknikken ikke er så udbredt som man kunne foranledes til at tro.

Unittests - modultests på dansk - er en programmatisk test som tester en lille programstump. I et objektorienteret program kan det være tests af alle metoder i klassen, hvor der på klassisk vis skabes test for parametres grænseværdier: typiske, ekstreme og ugyldige værdier.

Det meste kendte miljø inden for genren er Junit til Java, som fik stor popularitet ved at være indbygget i værktøjerne Eclipse og Netbeans. Bag Junit stod bl.a. Kent Beck, manden som opfandt XP-metodikken.

Blandt de tegn, som Andrew Binstock ser på, at der ikke er den store reelle interesse for unittests, er blandt andet, at firmaet Agitar, som har produceret værktøjer til unittests, måtte dreje nøglen om sidste måned.

Mængden af open source-software på området er en anden indikator, mener Binstock. Her er xUnit-projektet, som blandt andet står bag Junit, stort set det eneste som har en vis fremdrift, skriver han.

Andre tegn er de få bøger, som skrives om emnet, og der holdes heller ikke mange kurser om emnet. Endeligt er der stort set ingen kendskab til alternative miljøer som TestNG.

Andrew Binstock understreger, at han mener, at unittests er den vigtigeste fordel som gennembruddet for adrætte metodikker har medført.

Han kan ikke pege på nogen præcis grund til at unittests ikke har slået mere igennem, end tilfældet er. Én årsag kan være argumenter om, at al kode skal dækkes hundrede procent, og det krav kan være svært at opfylde for programmørerne.

Din mening:

Har Andrew Binstock ret i, at unittest er på vej ud? Deltag i debatten nedenfor eller giv din mening til kende i Version2's barometer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Carsten Frigaard

Nu 'SKAL' unittest ikke dække koden 100%, man kan gøre som man vil.

Under alle omstændigheder så kan man alligevel ikke dække alle kombinationer af data-værdier og kode-stier, så "100% code coverage" er en narresut under alle omstændigheder.

Unittest kan da også anvendes på ikke-objektorienterde sprog. Ideen er egentlig at man istedet for at debugge kode skriver test-stumper, som man så kan køre igen og igen...med andre ord en form for automatisering i forhold til kedelig debugging.

Sidst kan man også forstille sig, at man bruger hjemmelavede unittest code, der skal jo ikke mere en 100 til 200 linier til for et relativt avanceret testværktøj.

Man kunne også spørge sig hvor mange der egentlig bruger 'Design Patterens', som jo også i sin tid blev udråbt som en 'Silver Bullet', som alle referere til, men som få bruger i praksis.

mvh
Carsten

Thomas Ammitzbøll-Bach

Er det mig, der er dum, eller virker det uklart, hvad artiklens budskab er?

Hvis cyklisterne i København kører uden lys efter mørkets frembrud, kunne overskriften så hedde "Cykellygter er på vej ud"?

Andrew Binstock ser unittests "den vigtigeste fordel som gennembruddet for adrætte metodikker har medført." Hvis det er rigtigt, så er det jo forsømmelse, at der ikke skrives unittests.

Det kan der jo være mange forklaringer på, men det største løft, man kan give sin softwarekvalitet, er jo netop at indbygge automatiserede tests i alle dele af systemet. Det er svært at komme udenom.

Måske er det et symptom på, at de andre practices i XP ikke bliver fulgt (pair programming, feature cut i stedet for quality cut, refactorization, etc.) XP er en igloo, og hvis man ikke bruger alle practices, så falder blokke ned.

Thomas

Simon Lyngshede

Jeg tror du har fat i noget rigtigt. Unittest er ikke på vej ud, det har aldrig været inde, ikke sådan rigtigt i hvert fald.

Virksomhederne synes ikke rigtigt at sætte pris på de udviklingmetoder hvor unittest er en naturlig del og de virker mere end alm. ligeglade med unittests som en selv stændig praksis. Jeg tror det er fordi der ikke er et direkte økonomisk afkast af unittests i sig selv, efterhånden er jeg ved at lære at hvis der ikke er en umiddelbar økonomisk gevinst ved noget, så springer virksomhederne over. Dermed ikke sagt at der ikke er økonomi i brug af unittests, den kommer bare lidt længere uden end virksomhederne kan se.

Paw Mejdahl

Som netop nyuddannet kan jeg fortælle at vi i undervisningen modtager god undervisning i både unittest og design-patterns (GoF og GRASP).

I min korte tid på arbejdsmarkedet har jeg oplevet at det er op til kunden hvor grundig en kravspec. der skal udfærdiges og hvor grundige tests(blot systemtest eller både unittests og systemtests) der skal foretages. Det hele afhænger af $.

Patterns derimod vil jeg aldrig undvære. Det handler kort og godt om god og udviklingsvenlig kodestruktur. Dette er kun en fordel min udvikling, evt. andres videreudvikling og for udviklingstiden.
Det min oplevelse at stortset alle fra min årgang er af samme opfattelse.

Mejdahl.

Thomas Ardal

Det er efter min mening den værste gang vås jeg længe har hørt. Min opfattelse er, at unit test bliver mere og mere udbredt. Begrebet er blevet misforstået i mange år, men jeg synes at kunne se en tendens der går i den rigtige retning.

Jeg har afholdt flere kurser i .NET i løbet af det sidste halve år og hver gang har der været efterspørgsel på unit test, test-driven development, dependency injection osv. Så at påstå at unit test er på vej ud, hænger slet ikke sammen med den efterspørgsel der er på markedet.

Og med hensyn til unit test relaterede projekter, er der udover JUnit stadig skub i NUnit til .NET og Microsoft har ligeledes udviklet deres MSTest, der spås en stor fremtid indenfor den verden.

Carsten Frigaard

Måske er det ideen med direkte at sælge unittest værktøjer, der halter. Man kan lave unittest selv, simpelt, billigt og nemt at vedligeholde.

Der er jo ingen grund til at overkomplicere sagerne, eller med andre ord: KISS.

Herudover er jeg glad for at høre, at Design Patterns bliver brugt...jeg har bare mødt ret mange udvikler siger "Patterns, patterns, patterns" uden at kunne nævne et eneste specifikt mønster selv.

mvh
.carsten

Torben Frandsen

Herudover er jeg glad for at høre, at Design Patterns bliver brugt...jeg har bare mødt ret mange udvikler siger "Patterns, patterns, patterns" uden at kunne nævne et eneste specifikt mønster selv.

Jo, men prøv at kigge på deres kode. At de ikke lige kender til patterns betyder ikke, at de ikke anvender dem.

GoF opfandt jo ikke de patterns. De destillerede bare suppen, så det blev muligt at genkende de ting, man gør igen og igen.

Jens Madsen

"Én årsag kan være argumenter om, at al kode skal dækkes hundrede procent, og det krav kan være svært at opfylde for programmørerne."

Jeg kender ikke til unittest indenfor software, men indenfor hardware, er det med til, at vi kan få ganske store konstruktioner til at fungere:

1: Når en blok, af komponenter er testet, og eventuelt bevist, så ved vi den fungerer, og behøver ikke at gøre mere ud af denne komponent.
2: Vi kan anvende komponenten, et utal af gange, og det eneste vi skal bevise, er at sammensætningen fungerer.
3: Vores blokke, må ikke være for store. De skal altid være overskuelige, så de ikke er komplicerede at teste. Idéen er ikke at lave flere hundre megabyte kode - typisk er en blok kun få siders kode, eller en enkelt. Der er dokumentation til, og den er testet. Idéen er, at jo flere blokke du har, jo mere "blok opbygget" er din konstruktion, og jo simplere er det at teste.

Tager du en komplet computer, indeholder den i princippet kun få blokke. Disse blokke indeholder igen blokke, som indeholder blokke osv. Helt ned til transistor niveau. Hver enkelt niveau, er testet, og der er kortlagt hvilke egenskaber den har, også når den sættes sammen med andre komponenter og der eventuelt er støj.

Min påstand er, at hvis "koden" er for stor, til at blive unit testet - så er den ikke modulopbygget nok.

Ethvet modul, skal være lille, og have en veldeffineret og testbar funktion.

Jeg tror, at mange softwarefolk, begår den fejl, at kun anvende få niveauer. Et niveau, bestående af bibliotekskomponenter. Og et andet niveau, bestående af den komplette kode... Dermed, opnås kun éen unit, da bibliotekskomponenterne nok er testet.

Prøv en bedre opdeling, mindre koder, se om det er muligt at lave noget "smart", så der kan "opfindes" komponenter, der løser problemer, og bruge disse komponenter effektivt. Ofte bliver koden mere testbart, mere modulopbygget, mere overskueligt, og mere simpelt, og resultatet bliver ofte et program der fylder færre bytes oversat.

Nås niveauet, hvor der ikke "orkes", at teste et modul, er meget som tyder på, noget er gået galt. Modulet er sandsynligvis for stort, og for uoverskueligt. Måske bør der startes forfra, for at systematisere og forstå hvad modulet skal, og opskrive de nødvendige delmoduler, der vil være hensigtgsmæssige at bruge. Disse delmoduler udvikles og modultestes, og herefter kan det sættes simpelt sammen til et nyt modul, der kun består af testede dele, og er simpelt at teste.

Derudover, er altid en god idé at teste to gange: Både de moduler der anvendes, samt det moduler, man selv har udviklet. Det er bedst at give fejlmelding til et testet modul, hvis der opdages en fejl, så hurtigt som muligt - fremfor at det opdages fejl i ens eget modul, og det viser sig, at være en af de brugte moduler som fejler. Der er risiko for, at man har misforstået brugen af det brugte modul, og en test af ens forståelse, er derfor ofte nødvendigt. Har man selv udviklet den, og testet den, er arbejdet måske gjort, men alligevel kan det i nogen tilfælde være godt at arbejde sig ud fra funktionen.

Endeligt, kan oftest anvendes nogle redskaber, for at se om noget er glemt ved testningen. Det kan være at tjekke alle programlinier er gennemgået ved testen, alle retninger mv. Dog, burde det være trivielt.

Til et modul hører altid testvektorer, og de bør altid fremgå af dokumentationen.

Jens Madsen

Et andet problem, som også ses, dog sjældnere, er for meget modulopbygning. Det er kendetegnet ved, at der er tusinder af moduler, som er svært at overskue. De er ikke modultestet, og de har ingen, eller kun dårlig dokumentation. Et enkelt modul, kan måske kræve kenskab til tusinder af moduler, som kræves gennemlæst og forstået. I nogle tilfælde, kan være bedre, at simple moduler er implementeret direkte, således det forstås, ved at se i programmet. Eksempelvis, bør man ikke implementere grundlæggende funktioner som et modul. Et modul, skal have en "fornuftig størrelse".

Antages eksempelvis, vi har et udtryk, der kan opskrives i en simpel sætning i C++, så vil ofte være mere overskueligt at indtaste dette udtryk, men naturligvis huske at dokumentere det ordentligt. Hvis det er for kompleks til at dokumentere, skal det måske deles op i flere moduler, eller funktioner.

Sædvanligvis gælder altid, at holde tingende simpelt, overskueligt, godt dokumenteret, og angive testvektorer i dokumentationen, så andre også kan se modulet er testet. Der må aldrig eksistere et modul, som ikke er dokumenteret og med testvektorer. Er det ikke nødvendigt, burde det måske ikke være et modul...

Log ind eller Opret konto for at kommentere