Moede Kbh Maj

Test-first - erfaringer og anbefalinger - Arvinder Singh, Motorola

Fakta om projektet:

   * Udvikling af en test-workbench til Corba-applikationer hos Motorola
   * Lille team – 3 mand – alle arbejder med alle discipliner – 8 mandemåneder
   * Programmeringssprog: Java
   * Testværktøj: JUnit
   * Workbench-projektet leverede ”on budget” og ”on time”
   * Workhenchen har nu kørt i 5 måneder, og der p.t. ikke konstateret en eneste fejl

Beslutningen…

Test-first kræver en hård beslutning. Det, at ”vende tingene på hovedet” – og tænke tests før man tænker i programmering af selve systemet – har en stor indflydelse på arbejdsformen i et projekt. Det er ikke noget, som man kan gøre ”lidt” – og det er ikke noget, som kan gennemføres af en delmængde af projektets udviklere. Derfor kræver det en beslutning tidligt i projektet – og at alle committer sig til den måde at arbejde på.

Udgangspunkt for tests

Tag også udgangspunkt i Use Cases. I dette projekt blev der primært taget udgangspunkt i design og modeller, når tests skulle identificeres og programmeres. Der var nogle huller i den ”første udgave” af de tests, der blev udviklet. Hullerne blev fundet – og der blev undervejs udviklet flere tests til at stoppe hullerne. Det var sådan set OK, men der var en fornemmelse af, at man havde haft en bedre ”første udgave”, hvis man også havde brugt krav, Use Cases, normalforløb og varianter som input til arbejdet med at identificere hvilke tests, der skulle være.

Husk fejl-scenarier. Man har tendens til at nedprioritere at få testet fejl-scenarier – altså få testet om systemet opfører sig som forventet i fejlsituationer. Nogle af disse tests vil komme fra Use Cases – men ikke dem alle…

Is i maven - undervejs

Test-first ER til gavn senere. Undervejs i projektet var der til tider en følelse af, at der ikke blev produceret nok produktionskode. Projektets succes viser, at disse følelser ikke havde noget på sig. Erfaringen er nok, at det kræver is i maven – og en stærk tro på at investeringen i specifikation og implementering/programmering af tests i starten af projektet – er til stor gavn senere i projektet.

Test-first og design

”Design on the fly”. Detaljeret design blev erstattet af arbejdet med test-cases og ”design on the fly”. Det gav en god fornemmelse – fordi:

   * programmerede tests er mere forpligtende og mere operationelle end tegninger og beskrivelser af designet
   * tests bliver skrevet i et programmeringssprog, som nok er mere systemudviklernes end diagrammer og prosa-beskrivelser

Test-first giver bedre modulopbygning. Test-first får indflydelse på den måde systemet designes på – i positiv retning. Automatiseret test-first kan kun gennemføres på et modulært opbygget system. Derfor trækker test-first i retning af en bedre modul-opbygning af systemet.

Arbejdsform

Pair programmerér tests. Test-first er jo blot en af XP disciplinerne – hvor ”pair programmering” er en anden. I dette projekt blev der ikke pair programmeret så meget. Hvis man kun kan (holde ud at) pair-programmere en del af tiden, så er det bedst at bruge pair-tiden på at pair programmere tests – for hvis der ikke er nogen fejl i tests, så kommer der heller ingen fejl i systemet.

Skills er vigtige. Test-first – og det afledte ”design on the fly” – er en anden måde at arbejde (sammen) på, end traditionel udvikling. I denne arbejdsform viser det sig, at skills er vigtige. Det gælder både bløde ting som kommunikations- og samarbejdsevner – og det gælder de lidt hårdere discipliner som systemdesign og programmering.

Test-first – hurtigt og effektivt

Hurtig afvikling af tests. Afviklingen af tests bliver en naturlig del af udviklingsarbejdet, fordi det er så hurtigt og let. Et eksempel på hvor hurtigt det går: 150 af systemets testcases kan gennemføres på 2-3 minutter

Stor dækning. Selvom det ind i mellem føltes som et stort arbejde at programmere tests, så føltes udbyttet af at have de automatiske tests, og køre dem igen og igen mange gange større. Effekten var, at der blev lavet flere tests, hvilket gjorde, at dækningen (”coverage”) blev større end normalt.

Automatisk test fanger flere fejl. Fejl, som kan være svære og/eller besværlige at fange i en manuel test, lader sig nemmere fange i en automatiseret test. Det skyldes, at man en gang for alle kan programmere det, der er lidt besværligt at gøre manuelt, og så bare kan køre det igen og igen. Et eksempel kan være test af, om systemet kan klare mange kald til samme metode hurtigt efter hinanden. Det kan være næsten umuligt, at teste manuelt, men er let at teste, når man bruger automatiseret test.

Overdragelse

Tests en del af leverancen. Da workbenchen skulle overdrages i slutningen af projektet var det helt naturligt at de programmerede tests var en del af leverancen.

---

Presumably something to do with the DanishAgileUserGroup