Kodning och tester

Koda

Bara några korta tankar som inte fått plats någon annanstans:
  1. Designen kan aldrig bli så bra att kodning är en rent automatisk implementation av designmodellen. Vid kodningen kommer säkert oklarheter och felaktigheter i designen att upptäckas, det är helt OK. Det finns inget egenvärde i att uppdatera designmodellen med upptäckterna som görs vid kodning. Oftast är det lämpligast att köra reverse engineering på koden vid nästa iteration och då skapa en aktuell designmodell.
  2. Försök få koden så tydlig att den förmedlar designen. Detta åstadkoms främst genom att hålla klasser och metoder små och att ge dem bra namn. Det är klart eftersträvansvärt att det ska gå att förstå programmets struktur genom att läsa koden.
  3. En klass/metod i designmodellen resulterar ofta i flera klasser/metoder i koden enligt ovanstående resonemang.
  4. Skriv en javadoc-kommentar till varje publik klass, interface, metod och variabel. Använd gärna taggarna @param, @return och @throws för metoder.
  5. Förutom ovanstående är det ofta bättre att dela metoder och ge de nya mindre metoderna tydliga namn än att skriva kommentarer i större metoder.

Skriv tester

Desto fler tester desto bättre... Att skriva tester tar visserligen en hel del tid men det sparar också mycket tid. Har vi en stor samling bra tester blir det mycket lättare att ändra i koden eftersom vi lätt kan verifiera om ändringarna fungerar.

Unit Test

Det bästa är att ha ungefär en testklass per klass men åtminstone en testklass per paket krävs. Dessa tester (kallas unit test) ska testa alla potentiella fel i det publika gränssnittet, tex att metoder ger förväntade returvärden under olika omständigheter och att undantag kastas när de ska. Så fort en bugg dyker upp, skriv ett test som identifierar den och låt sedan det testet finnas kvar så inte buggen dyker upp  på nytt.

Testprogrammen ska även utvärdera resultatet av testet. Om testet misslyckas ska testprogrammet skriva ut var felet uppstod, vilket det förväntade värdet var och vilket det verkliga värdet var. Om testet lyckas ska det inte göra någonting.

Ett testprogram blir förmodligen ungefär lika stort som den kod det ska testa.

De renläriga skriver testet först och det program det ska testa sedan. Detta är kanske inte helt enkelt i början men om orken räcker finns det ett par klara fördelar med det. Dels tvingar det oss att fundera över det publika gränssnittet innan vi börjar koda (och att vara helt klara över den önskade funktionaliteten), dels är det lätt att verifiera den utvecklade koden bit för bit och slutligen är det tydligt när utvecklingen är klar, det är helt enkelt när alla test fungerar.

Acceptanstest

Dessa tester ska verifiera att hela systemet fungerar som kunden önskar. Främst görs de genom att kolla att programets beteende stämmer med scenariona i use case-modellen. Vi ska dock också kolla att eventuella krav från supplementary specification är uppfyllda och att användargränssnittet stämmer med UI-prototypen.