Statiske metoder med kompleks logik, singletons og reflection – og kombinationer deraf.. Det er alle ting, som jeg har erfaret, gør det temmelig besværligt at skrive fornuftige tests.
Hvordan skriver man f.eks. en unit test til en metode, som kalder en statisk metode? I særdeleshed hvis den statiske metode skulle risikere at kommunikere med f.eks. en database, en webservice eller et helt tredje eksternt system? Den eneste mulighed er vel, at man kan håbe på, at man kan afkoble ressourcerne, som den statiske metode benytter. I mine øjne er det ikke optimalt.
Når det kommer til singletons, er det lidt den samme historie. Hvordan tester man en metode, som anvender en singleton? Igen kan jeg kun se, at man kan gøre det ved at afkoble de ressourcer, som singletonen anvender eller lave en “hemmelig” statisk metode i singletonen for at kunne overskrive singletonens reference til instansen.
Når det så kommer til metoder, der anvender reflection – så går det rigtig galt. Hvis det er i Java, og det omhandler loading af klasser, så skal man vel ud i noget med at fuske med class path og lave en stub/mock-implementation med samme FQN, som så bliver loaded via Class.forname i stedet for den rigtige klasse. Hvordan det lige forholder sig med metodekald via reflection, kan jeg slet ikke forestille mig lige nu.
Nu håber jeg bare, at jeg husker, at jeg har skrevet denne blogpost – det er nemlig mest af alt for at gøre mig selv klogere (eller i hvert fald prøve på det) samtidig med at tage ekstern hukommelse i brug; det er ikke for at udbrede viden – det er der andre, der er meget bedre til end mig.
Forresten! Hvis du ser mig være igang med at bruge nogle af de ovenstående ting, gider du så ikke lige prikke mig på skulderen, minde mig om denne post og spørge mig, om jeg virkelig har tænkt det igennem?
På forhånd tak!
Endnu mere forresten! Har du gode ideer til, hvordan man tester kode, hvor det ovenstående indgår, eller at jeg tager fejl, så må du meget gerne oplyse mig.
På endnu mere forhånd tak.
Related posts:
Først af alt, så prøv at finde en kopi af Michael Feathers bog: “Work Efficiently with Legacy Code”. Han adresserer netop problemet med at unitteste kode, som er lavet før, nogen havde tænkt på muligheden for unittest (…eller måske bare lavet det unittest-fjentligt).
Et trick kunne være, at virtualisere referencen til disse trælse ressourcer. Så kan man komme med en alternativ implementation i stedet. Hvis ikke man kan få lov at introducere et interface at virtualisere over (f.eks. fordi at det er en 3. parts jar), så kan man wrappe de relevante dele, og introducere interfacet i wrapperen. Der findes mange fine patterns for, hvordan man får instantieret på en måde, så man kan variere implementationen.
Men det har du sikkert allerede tænkt på selv, så det er nok mere kompliceret end som så.
“Working Effectively with Legacy Code” står helt sikkert på min liste af bøger, jeg skal have læst – rent faktisk har jeg netop bestilt den. Jeg er slet ikke i tvivl om, at den giver en masse gode tips, jeg kan bruge.
Jeg må sige, at jeg ikke har tænkt så meget – mere taget mig til hovedet. Problemet er lidt det med hønen og ægget – for at kunne teste, er man nødt til at refaktorere, men for at kunne refaktorere sikkert, er det nødvendigt at have tests
Men formentlig kan jeg lave noget afkobling vha. en wrapper på en rimeligt sikker måde, hvor jeg kan have tillid til, at jeg ikke ændrer kodens opførsel.