objektorientering | OlofB[eta]

Varför enhetstesta – anledning 3

26 december 2008

images7 Inlägg i denna serie, ”Anledningar att enhetstesta”:

Anledning 3 – Designeffekten

Vi är framme vid anledning 3: renare kod – Designeffekten.

Det kan vara svårt att föreställa sig hur stor skillnad det gör på arkitekturen hos ett mjukvarusystem att börja enhetstesta den, eller till och med skriva enhetstester ända ifrån början.

Den huvudsakliga anledningen till att det gör en sådan skillnad är följande:

Det är svårt att testa ”fulkod”.

Tänk på det en stund. Tänk på vad du anser att fulkod är.

Med fulkod menar jag globalt tillstånd (statiska variabler), beroendegalenskap t.ex. ”spindelklasser” (även kända som ”control freaks”) som känner och kontrollerar tjugo andra klasser (rotar kanske t.o.m. i deras interna data, gud förbjude..), kod i användargränssnittsklasser (logik i event handlers t.ex.), kod som är för nära knutet till databas- eller filsystemslagret av systemet, kod som gör logiska beräkningar nära eller i utritningslogik för grafik etc.

Du har säkert en känsla av vad som är ”fulkod” om du programmerat mer än på nybörjarnivå.

Att det är svårt att testa sådan kod kommer du att lära dig om du börjar enhetstesta ett befintligt system som är lite skräpigt. Jag kan avslöja att en anledning är att koden är så beroende av tredjeparts-API:er vilket gör att testkod måste interagera ganska intimt med biblioteket ifråga – något som tyvärr ofta är om inte omöjligt så åtminstone rejält besvärligt.

När du använder dig av Test-Driven Development (TDD) vänder du på steken: du skriver tester innan du skriver kod! Givetvis blir klasser som designas efter denna princip (tester först!) mycket lättare att testa. Då måste du skriva koden mer eller mindre fritt från inblandning av beroenden, eftersom beroenden är så svårtestade. Givetvis måste din kod fortfarande interagera med tredjeparts-APIer men du kommer att behöva skikta systemet och abstrahera bort detaljer som exakt vilket tredjeparts-API ditt program använder sig av.

Men det som är intressant, och samtidigt svårt att förstå, är att testbar kod per automagi blir renare, snyggare och mer ”pattern-inriktad”/”objektorienterad”/”pick-your-fancy-word”-aktig kod! Pröva själv med ett hemmaprojekt. Så får du se!

Tidigare avsnitt i denna serie:

Anledning 1 – Dokumentationseffekten

Anledning 2 – Säkerhetsbälteseffekten

Taggar: programmering, enhetstestning, enhetstester, tdd, patterns, objektorientering