OO dur ikke til unit test

Unit test af en klasse passer da perfekt med at man via tests specificerer den kontrakt, som klassen har med omverdenen. Dette gøres ganske naturligt via klassens public metoder, og man sikrer sig på samme måde via disse at klassen opfører sig som forventet.

Mht. polymorfe argumenter, så passer det jo OGSÅ perfekt, idet man blot fremstiller en mock-implementation til at teste med. Hvis man så ellers kan finde ud af at bruge visitor-mønsteret i tilfælde af at forskellige specialiseringer skal behandles forskelligt, så kører det jo derudaf!

Efter min mening så bliver designet helt automatisk bedre og mere OO af at blive skrevet til test.

Jeg er ikke helt sikker på, at du har ret i udsagnet om, at skjult tilstand og nedarvning betragtes som god latin i de lærebøger om OO.

Eksempelvis Josh Blochs "Effective Java," som anses for lidt af en bibel blandt Java-folket, fraråder både nedarvning og tilstande, og den er immervæk fra 2001.

Med venlig hilsen
Tania Andersen

Det er vel et fundamentalt valg om man bare vil teste en klasses ydre (public funktioner) eller også fortage test af indre metoder og tilsande (private).

Klart giver den sidste metode mere arbejde, og bryder ind i en klasses flow på en ikke-intuitiv måde. Det er derfor ret besværligt at gøre konsistent...så jeg holder på almindelig test af ydre; der er simplere, og indmaden i klassen kan ændre uden at det i princippet går ud over test-case'ene.

Et andet spørgsmål er så hvad man mener med OO, når nu Tania skriver at Java guidelines fraråder nedarvning...et argument jeg egentlig godt kan følge.

Er det egentlig ikke OO der er problemet og ikke unittest?

Smalltalk har da unit testing med. Og det må siges at være OO :-)

Mener du virkelig, at en test med en enkelt mock-implementering af en argumenttype sikrer, at klassen virker med alle mulige nedarvninger af argumenttyperne?

Jeg mener at ENTEN er det ikke nødvendigt at bruge arv og specialiseringer, eller OGSÅ er det bare en del af din klasses kontrakt at den kalder noget på din argument-klasse. Og det kan du teste at den gør.

Så er det op til de unit tests du har af hver argument-type at verificere at de overholder deres del af kontrakten.

Det vil sige, at den, der skal lave unit tests for en klasse skal kende kontrakterne for alle de metoder, hvor denne klasse kan bruges som argument.

??? Det forstår jeg ikke. Tag f.eks det her:

1: A, givet en B, lover at kalde foo() derpå.

2: C er en B og har en implementation af foo(), der fungerer.

Hver af disse udsagn kan testes i hver deres unit test.

Hvad de i fællesskab kan udføre når de kobles sammen er et andet spørgsmål. Det kan man teste med integrationstest.

Hele ideen med unit-test og (s|r)spec, er at teste ydersiden (og kun ydersiden) af et eller flere objekt(er). Hvad der sker indeni er et udelukkende et implementationsspørgsmål. Dette falder rigtig godt i hak med test-first filosofien - først laves objektets specifikation (testen), og så laves implementationen (koden der får testen til at gå i grøn).

Hvis ikke man er i stand til at beskrive hvorledes objekterne skal opføre sig i enhver tænkelig situation (yderside situation), så har man meget større problemer end manglende unit-tests.

Jeg tror mange forveksler unittest med gammeldags whitebox test, hvor den interne logik i en funktion blev aftestet. Unittest er netop kendetegnet ved, at den ikke tester intern logik, men udelukkende ser på kontekst hvori unit indgår. Det kan derfor bedst sammenlignes med gammel blackbox test, dog på et lavere abstraktionsniveau.

Der testes altså på, hvilket output unit producerer i forhold til det modtagne input. Intern tilstand og polymorph egenskabs påvirkning af output er derfor ikke relevant for en unittest, fsv. dette ikke har indflydelse på output.

Jeg ville mere betragte unittest som en avanceret form for grænseværditest.

(forudsat, at hverken A eller B har for meget skjult tilstand)

Mængden af "skjult tilstand" er vel underordnet, hvis bare klassen opfører sig som den lover. På den måde opnår man indkapsling.

Se DET er OO! Og DET kan testes :-)

Derfor kan en test med et givet argument og resultat, der opfylder kontrakten, ikke garantere, at samme argumenter også næste gang giver et resultat, der opfylder kontrakten.

Som generel betragtning er det her naturligvis korrekt - man kan jo aldrig vide, om klassen "husker" f.eks hvor mange gange getLength() er blevet kaldet, for den 42. gang at returnere noget forkert.

Men som regel vil man jo selv skrive sine unit tests, og dermed vil man formentlig teste koden rimelig fornuftigt - f.eks i noget, som man skønner kunne være vanskelige situationer: grænsetilfælde, uventet input, osv.

Hvis man så en dag finder ud af at klassen opfører sig uventet med en given tilstand, så er det jo bare at genskabe tilstanden og fejlen via en test, og så kode til verden bliver grøn igen.

man kan jo selv bestemme hvad man vil bruge sine unit tests til. Jeg er selv meget tilhænger af testdriven development hvor udviklerne laver testene samtidigt med de laver selve koden således at koden bliver testbar.

At objekter kan have en skjult tilstand gør ikke unit tests ubrugelige. Hvis man mener den er relevant for sin unit test bliver man nødt til at åbne op for klassen for at den er testbar.

Nedarvning har ingen relevans. Man bliver nødt til at fokusere på hvad det egentligt er man tester. Man er nødt til at fokusere på det niveau der opereres på og ikke teste for alle mulige nedarvninger af en parametre. Nedarvninger synes jeg man skal teste for sig selv i en anden kontekst.

"Hvis unit tests bliver skrevet med kendskab til implementeringen, så er det ikke længere black box."

Nej, skal det absolut være det? "Rød-grøn-refactor"-cyklen gør at implementationen udvikler sig i takt med at unit-test-suiten udvikler sig, så jeg synes ikke man kan betragte unit-tests som black-box-tests. Det er med at finde den rigtige balance.

"Ideelt set skal unit tests skrives af en anden end implementatoren"

Det var da en pudsig opfattelse. Det er sundt at få reviewet sine unit-tests af andre (ligesom man også bør få al anden kode reviewet af andre), men man bør skrive sine unit-tests ud fra "rød-grøn-refactor"-devisen. Så giver de ganske enkelt mest værdi, da man så "up front" undgår at skrive en masse fejl som andre (og en selv) kommer til at lide under sekundet efter du har committet koden til dit kode-repository.

Og mht. argumenterne om skjult tilstand osv.: Hvad værdi giver kode som måske er meget pæn i din editor, men hvor du ikke aner om det virker? Har du for megen skjult tilstand i dine objekter, så refaktorér til noget mere gennemskueligt.

Jo, Carsten, problemet er OO og ikke unit test. Prøv lige at læs titlen igen. :-)

He, ja det står jo ligesom også i overskriften :-) Interessant er, at vi når samme konklusion!

mvh
.carsten

Jeg tror at en del har svært ved at se hvorfor objekt-orientered sprog ikke er så velegnet til unit-testing som funktionelle sprog, fordi ikke kender til alle fordelene ved testing i et funktionelt miljø. Jeg har fundet en video med en af Haskell-"bagmændende" (Simon Peyton-Jones), der omhandler netop dette:

http://www.foomongers.org.uk/videos/spj-typedriventestinginhaskell.html

Den er primært rettet mod folk der ikke kender til funktionsprogrammering.
Det vigtigste at få med er nok hans eksempel med test af en SMS-encoder (der pakker 7-bit tegn ned i 8-bit bytes). Se den :-)

I har ikke fået mig overbevist om at jeg skal droppe OO til fordel for funktion orienteret programmering. OO giver en enorm fleksibilitet bla. vha. nedarvning. Det er f.eks. helt åbentlyst at bruge OO til at kunne dele en opgave ud på flere personer der så hver især kan udvikle dele af applikationen, unit teste den og til sidst sætte den sammen uden at skulle ændre noget i de dele der allerede er unit testet.

Det er fair nok at i er glade for funktions sprog, men det gør ikke nødvendigvis OO uegnet til f.eks. at unit teste.

Min opfattelse fra ovenstaaende diskusion er desvaerre at flere folk betragter unittest som en metode til at naa korrekte prgrammer. Men det er logiskt at tests ikke viser om hvorvidt kode er korrekt eller ej, med mindre at alle kombinationer er afproevet. En af de foerste artikler http://www.google.dk/search?q=structure+test+software er http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/
Har hurtigt skimtet denne og mener at der her er tale om et fornuftigt syn paa situationen. Hvis kontrakt orienteret udvikling/design er saa meget i folks bevidsthed, burde flere vaerdsaette Ada's struktur: *.ads og *.adb (Ada specification og Ada body) og her er der tale om aegte kontrakter - ikke C++'s underlige bastard headere. Ada er frit og helt fra begyndelsen var software engineering en del af sproget. Korrekt kode.

Unit test virker fint i OO. Men opfatter man generelt det at teste kode via white- eller blackbox metoder, som en metode til at bevise korrekthed af programmel paa, er man ude i hampen.

Haaber ikke nogle folk har ladet sig overbevise om at der er endnu er fundet en "silver bullet" til software krisen.
"Software crisis" paa Google for mere info om emnet.

Men giver det overhovedet mening at teste for et brugsmønster som ikke giver mening? Hvis du skal teste funktioner for alle brugsmønstre skal du jo også kunne teste den mad alle mulige input. Det er ikke realistisk.

Problemet er, at det er ret svært at forudsige de mulige brugsmønstre bare nogenlunde præcist

Er det nu også formålet med test? I min optik består test af to trin:
1) Identificer den lovlige delmængde af inputværdier fra populationen.
2) Skriv test for afprøvning af denne delmængde.

Overført på dit eksempel mangler der en definition af den lovlige mængde af input. I f.eks. C++ ville en assignment metode i en klasse altid teste for "self assignment":

Foo& Foo::operator= (const Foo& f) {
if (this == &f) return *this; // Håndter self assignment

// Normal håndtering af assignment

return *this;
}

Det der går galt i dit eksempel, er den manglende håndtering af self assignment, hvilket burde have været en del af designet.

Det virker ku, hvis du er sikker på, at dine metoder aldrig bliver kaldt med værdier udenfro denne mængde, så hvis ikke typen i sig selv sikrer dette, så skal din kode test for inputtets validitet, og din unit test skal teste, at denne test sker korrekt

Det var derfor jeg tidligere anlagde betragtningen, at unit test er en avanceret form for grænseværdi test. Punkt 1 i min to-trins model indeholder den implicitte antagelse, at der foretages inputvalidering; Består input ikke denne test, skal der returneres en exception (om denne så bør være checked eller ej, er en helt anden diskussion).

Er din definition af aliasing en interface type? I så fald tilbyder Java instanceof til at teste objekter på kørselstidpunkt. For en dybere validering tilbyder Java inspektion (reflection).

Da min opdragelse indenfor programmering tager afsæt i Pascal og C, er jeg opflasket med inputvalidering - Pascals var indbygget i sproget, og i C blev man vendet til at lave kontrol af returværdien fra funktioner ( if ((res = foo()) == 0) {....}), hvorfor jeg finder det naturligt, at lave inputvalidering af alle metoder i public scope.

Det er egentligt forbavsende så få Java programmører, der anvender sproget indbyggede hjælp til inputvalidering; jeg tænker her på assert. Jeg vil tro, at over halvdelen af alle køretidsfejl i Java skyldes NullPointerException, hvilket enkelt kunne have været løst med en kombination af inputvalidering og assert.

Et andet typisk eksempel er følgende - java er brugt som eksempel:

public class Foo {
Foo instance;

private Foo() {}

public static Foo getInstance() {  
    if (instance == null)  
        instance = new Foo();  
    return instance;  
}  

}

Kan du gætte fejlen i ovenstående, som jeg er 99% sikker på, de fleste ikke tester for med unit test?

Foo instance;

Skulle selvfølgelig have været erklaret: private static Foo instance; Det er altså ikke det, der var fejlen:-)

Fejlen er at dit singleton pattern kun returnerer instansen første gang den bliver kald.

Jeg vil konkludere til mig selv at unit test kun kan bruges til at teste de situationer man kender der vil give problemer. Det er altså ikke hvilken teknologi der er afgørende for om en unit test er effektiv, men udviklerens overblik. Funktionelle sprog har altså i min bog ingen fordel frem for OO til unit test.

Til Torben: Hvad er dine erfaringer med OO siden du er så skræmt af det?

Fejlen er at den ikke er trådsikker.

En anden pointe mht. unit test og OO, er, at unit test er en måde (hvis ikke det er mådEN) at fastholde de krav man har til sit system.

Noget af det gode ved OO er jo netop indkapsling af implementationsdetaljer, som er omverdenen uvedkommende - men hvordan sikrer man at koden stadigvæk er "korrekt" (altså ikke i algoritmisk forstand, mere i en bred "det blev vi enige med kunden om"-agtig forstand) efter en stor refaktorering?

Det gør man ved at have unit tests! Og der er - så vidt jeg kan se - ingen anden (praktisk lade-sig-gørlig) måde at gøre dette på.

Hvis man vil bevise at koden er matematisk korrekt, skulle man tage at kigge på nogle af de værktøjer der findes til kontraktbaseret programmering i stedet.

[qoute]Fejlen er at den ikke er trådsikker.[/quote]Ja, det var den åbenlyse fejl. Fejlen kan udbedres på følgende måde:

[code=java]
public class Foo {
Foo instance;
private Foo() {}

public static synchronized Foo getInstance() {  
    if (instance == null)  
        instance = new Foo();  
    return instance;  
}  

}
[/code]
Men der er en anden, og endnu værre, fejl, der relaterer sig til Java's objektmodel. Fejlen kunne Torben have brugt som argumentation for at unit test i OO er væsentligt vanskeligere end i funktionsprogrammering.

Årsagen til fejlen skal findes i Java's indbyggede regel om, at alle objekter implicit arver fra Object. En af metoder i object har følgende forskrift:

[code=java]
protected Object clone();
[/code]
Umiddelbart har det derfor ingen konsekvenser for vores klasse, men skulle fremtiden betyde nedenstående, kan vi risikere at stå med en logisk bombe:
[code=java]
class Bar implements Clonable {

public Object clone {  
    Object o = null;  
    try {  
        o = super.clone();  
    }  
    catch (CloneNotSupportedException e) {  
        System.err.println("MyObject can't clone");  
    }  
    return o;  
}  

}

class Foo extends Bar {
Foo instance;

private Foo() {}

public static synchronized Foo getInstance() {  
    if (instance == null)  
        instance = new Foo();  
    return instance;  
}  

}

Foo foo = Foo.getInstance();
Object o = foo.clone() /* Da super implementerer clone er det lovligt. Det var vist ikke meningen med en singleton! */
[/code]
For at udelukke denne situation, bør vores singleton derfor have følgende udvidelse:
[code=java]
class Foo Bar {
Foo instance;

private Foo() {}

public static synchronized Foo getInstance() {  
    if (instance == null)  
        instance = new Foo();  
    return instance;  
}

public Object clone()  
        throws CloneNotSupportedException {  
    throw new CloneNotSupportedException();   
    /* Ny kan man ikke lave en kopi af singleton  
     * grundet nedarvning fra super.  
 */  
}  

}
[/code]

Apropos inputvalidering, hvad ville du bruge til concat-metoden i mit eksempel?

Et forslag kunne være at implementere interfacet Comparable.
http://java.sun.com/javase/6/docs/api/java/lang/Comparable.html

[code=java]
class List<E> implements Sequence<E>, Comparable<List<E>> {

private E head;  
private List<E> next;

public E elem() {  
    return head;  
}

public List<E> advance() {  
    if (next == null)  
        throw new IndexOutOfBoundsException();  
    return next;  
}

public List<E> last() {  
    if (next == null)  
        return this;  
    else  
        return next.last();  
}

public void concat(Sequence<E> y) {  
    if (this.compareTo((List<E>)y) != 0)  
        last().next = (List<E>) y;  
    else  
        throw new RuntimeException("cannot concatenate to self");  
}

public int compareTo(List<E> o) {  
    List<E> y = this;  
    List<E> x;  
    try {  
        while (y.next != null) {  
            x = o;  
            while (x.next != null) {  
                if (y.equals(o))  
                    return 0;  
                x = x.advance();  
            }  
            y = y.advance();  
        }  
    }  
    catch (IndexOutOfBoundsException e) {}  
    return 1;  
}

}
[/code]
Bemærk dog det er en dyr kontrol, da kompleksiteten af metoden er O(n^2). Så der bør nok findes en anden løsning for store lister.

Glemte:
Forudsætningen er, at klassen i sin nuværende udformning vil loope uendeligt i last metoden, hvis concat tillader input fra lister, hvor fællesmængden af elementer mellem de to lister ikke er tom. compareTo metoden laver denne kontrol, og såfremt den finder blot et identisk element mellem de to lister, afviser concat med en RuntimeException. Ens i denne sammenhæng vil sige, at elementernes reference er ens, og altså ikke indholdet af elementerne. Hvis et element fra to forskellige lister har samme reference, vil de også have fælles reference til næste element.

"Hvis unit tests bliver skrevet med kendskab til implementeringen, så er det ikke længere black box.

Ideelt set skal unit tests skrives af en anden end implementatoren, kun med kontrakten som udgangspunkt -- ellers vil testen ofte have de samme underforståede (og potentielt forkerte) antagelser som implementeringen."

Som jeg ser det, er det dårligt, hvis unit tests ikke laves af den der implementerer. Årsagen ligger i ansvar: Den der implementerer, tager også ansvaret for, at sine ting fungerer, og derfor skal vedkommende også udføre de nødvendige tests. I princippet bør vedkommende udfylde et underskriftsblad på, at blokken er designet til at fungere, at den er testet, og at udvikleren er fuldt overbevist om den fungerer. Test vektorer vedlægges som dokumentation. Som udvikler, tages ansvar for komponenterne. Kun udvikleren kender indholdet (interne tilstande mv.), og specielt ved OOP er nødvendigt, at udvikleren står inde for resultatet.

Test 2 er, at du aldrig skal stole på udvikleren... Når du anvender et objekt, som en anden har udviklet, skal du have den nødvendige skepsis, og tage det med et vist gran salt. Det betyder, at du starter med at teste komponenten. Derved får du kendskab til komponentens funktion, og misforstår den ikke nemt. I nogle tilfælde, opbygges softwaren måske endog udfra de test du gør.

Enhver komponent testes derfor mindst to gange: Først af udvikleren, der står inde for resultatet. Herefter af brugeren (evt. anden udvikler), der står inde for overbevisning om at komponenterne som bruges er testet og fungerer godt, samt i sidste ende også står inde for sit eget resultat. Er du ikke overbevist om, at de komponenter du bruger fungerer, har du naturligvis problem med at udfylde underskriftsark vedrørende din komponent, da denne indeholder de andres værk (og dermed står du også inde for det).

Komponenter, der anvendes ofte, testes ofte. I princippet af alle der bruger komponenterne. Eventuelt kan vedlægges underskrifter fra alle der har testet komponenterne, og fundet de fungerer. Derved kan undlades at teste den så grundigt - til gengæld er det et problem for dem der har testet, hvis en test viser sig, at fejle.

Måske antages komponenter der bruges ofte, at være grundig testet, og udviklerne der anvender dem, bruger måske mindre tid på test - alligevel skal udvikeren være sikker på komponenten og stå inde for den, samt udføre de nødvendige tests, for at opnå det.

Mange typer af tests kræver kendskab til programmets interne opbygning og variable. Du skal ofte - som minimum sikre dig at alle programlinier er udførte ved testen. Ellers er testen ikke nok. Intet program kan være testet, hvis branch retninger ikke er udført, eller programlinier ikke er udført.

Du skal sikre dig, at ram forbruget er konstant, eller går op og ned, som beskrevet i dokumentationen. Visse sprog, kan have problem med at angive forbrug korrekt. Et sådant sprog, har problemer.

Disse ting, kræver til vis grad kendskab til indmaden, eller som minimum at kompileren kan forklare dette - f.eks. forklare om alle linier er udførte, samt alle branch retninger (alle branch retninger er samme som alle programlinier, hvor alle retninger anvendes, eller compileren internt har sat en "dummy" indstruktion ind, ved ikke brugte retninger, som også skal sættes flag på).

White-box tests, er som jeg ser det noget andet. Her tester du typisk input parametre mv. og at arrays ikke overskrider sine grænser. I de tilfælde, hvor det er muligt, at altid bedst at opnå sådanne tests, ved at have range tjek mv. indbygget i compileren. Men i tilfælde, hvor det har betydning for brugeren, f.eks. validering af indtastningsbokse, skal det naturligvis lægges i software. Programmeringssprog, skal helst håndtere range tjek osv. samt at variable kun må have værdier indenfor bestemte grænser. Det skyldes, at kompileren derved har kendskab til intervaller for variable og indexes, og det betyder meget for software analyse og automatisk parallelisering af software mv. Dertil kommer, at den type tjek ofte kan flyttes til hardware, og det er mere besværligt, hvis det står som kode. Range tjek, og lignende, er derfor tjek der skal gøres af compiler, og principielt er forkert at indbygge i objekter, da compileren så ikke får de nødvendige kendskab til variablers værdiområde og mulighed for at bestemme anvendelse af memory, eller at afsætte det rette antal bits i lageret (typisk vil være afsat for meget, fordi der "bare" siges integer, eller større). Compileren har ansvar for kompilering, og hvor mange bits den skal anvende, for at opnå et hurtigt program. Hvis systemet skal være fleksibelt, vil kompileren oversætte til ens kode, uanset CPU og dens arkitektur, og operativsystemet indeholder en CPU driver, der omsætter effektivt koden til CPU.

Formålet med unit test, er at programmøren kan dokumentere sine ting fungerer i form af dokumenterede test vektorer. Brugeren, laver også unit test af komponenterne. Alt er testet to gange som minimum. I slut enden, har vi hele applikationen, der kun er testet af programmøren. Her er nødvendigt med et test team, der tester programmet, set udfra "brugerens synspunkt", og udfører "brugertesten". Derved skulle alt være testet mindst to gange, inden det når til kunden - og man lader det ikke være op til "den perfekte programmør" om tingene fungere.

Kunden udfører så evt. ekstra tests, for at blive overbevist om, at produktet fungerer. Ellers, vil de ikke købe produktet. Dem der køber produktet hos kunden, skal sædvanligvis også være overbevist om, at tingene fungerer, og vedlægge underskriftsblad, troserklærringer osv. på produktet er ok, og at de har gjort det nødvendige for at sikre sig produktet er ok, herunder oftest udført egne tests.

Hele ovenstående mølle, er omtrent det at alt andet (end software) udsættes for. Såvel søm, som skruer... Dertil, findes masser af dokumentation, i form af tekniske og videnskabelige arbejder, der dokumenterer materialerne og deres levedygtighed, styrker, korrosion osv. Det er ikke simpelt at lave et søm.