Noen av oss kjører strikt, metodisk testdrevet utvikling. Andre bruker bare automatiserte tester nå og da som sikkerhetsnett for å unngå regress-feil. Hvor ofte fyrer du selv av testene dine? Kjører du testsuiten din en gang i ny og ne, eller strikt for hver metode du implementerer?

Jeg liker å kjøre testene mine ofte mens jeg arbeider. Det jeg liker enda bedre er å la utviklingsmiljøet mitt kjøre dem for meg, automatisk. Poenget med yrket vårt er jo nettopp å automatisere og effektivisere arbeidsprosesser – dette forsøker jeg å gjøre også med mine egne rutiner og verktøy. La oss se hvordan vi kan få til dette.

Mange av oss bruker allerede Continuous Integration for å oppdage feil i den felles kodebasen. Personlig autotesting er det neste, logiske steget: enhetstestene våre burde kjøre i bakgrunnen hver gang vi endrer noe, og gi oss umiddelbar tilbakemelding når vi knekker funksjonalitet. På denne måten oppdager vi våre egne feil før resten av teamet blir påvirket av dem.

Det finnes flere verktøy som gjør dette for deg:

• Infinitest (Java)
• Autotest / ZenTest (Ruby)
• Nosyd (Python)

Det er imidlertid ikke vanskelig å lage et enkelt autotest-verktøy på egen hånd. Jeg synes at det er en god ide å bruke litt tid her og der på å forbedre sitt eget utviklingsmiljø. Vi har jo muligheten til å lage våre egne verktøy (smeden er en av få håndverkere som kan si det samme). Som utvikler bør man iallfall klare å slipe sine egne kniver, for å si det sånn. Og dette er en god anledning!

Et naivt script for autotesting implementerer du på en ettermiddag. Alt du trenger er et lite program som reagerer på endringer i prosjektfilene dine, og kjører testene etter behov.

Algoritmen er enkel: La scriptet kjøre regelmessig, f.eks hvert sekund. Kontroller “forrige endring”-klokkeslettet for alle filene i prosjektet. Dersom klokkeslettet på en eller flere filer har endret seg siden forrige kontroll, så kjør enhetstestene til prosjektet. Analyser output fra testkjøringen, og se hvorvidt noen tester feilet eller kode knakk helt (exceptions). Gi så klar tilbakemelding om testene er ok eller feilet.

Tilbakemeldingen kan være litt grafikk og lyd på desktopen (for eksempel med Growl eller Snarl), en lavalampe på pulten, blinkende LED-lamper på laptopen… vær kreativ! Bare sørg for er at du får en tydelig tilbakemelding på hvorvidt testene feiler eller ikke.

Filmklippet under viser hvordan mitt eget autotest-miljø fungerer. Koden er i dette tilfellet skrevet i et språk som heter Clojure og ser derfor kanskje litt pussig ut, men ikke heng deg opp i det: det som demonstreres er at jeg knekker og fikser tester, og får automatisk godt synlig feedback på dette underveis.

Ikke spesielt komplisert.

“Dette ser jo genialt ut! Hvorfor bruker ikke alle autotest-verktøy allerede?”

Vel, det finnes dessverre noen utfordringer.

Dersom autotesting skal fungere hensiktsmessig må testsuiten som kjøres kun bestå av raske enhetstester, ikke tunge integrasjonstester. Og enhetstestene må gå kjapt! En test-run må ta sekunder, ikke minutter, ellers mister du gevinsten ved den umiddelbare feedbacken.

Problemet med trege tester er betydelig. Det finnes workarounds: man kan analysere avhengigheter mellom tester og kode, kun kjøre de berørte testene, kjøre raske tester først, feilende tester først, nylig feilende tester først… Men mange av oss har dessverre erfart at det er vanskelig å få til et godt fungerende opplegg for dette i et vanlig moderat stort utviklingsprosjekt.

Så er ikke autotesting nyttig likevel, da? Jo! Autotesting fungerer knallbra i små prosjekter (som ikke har samlet på seg så mye kode ennå) og egenopplæring (når du lærer nye verktøy og språk og ønsker å ta små steg med kjapp feedback). Det kan kanskje også fungere i større prosjekter dersom du har muligheten til å segmentere koden og testene dine i mindre moduler på en hensiktsmessig måte.

I bunnen av denne artikkelen har jeg vedlagt et eksempel på hvordan et enkelt autotest-script kan se ut, implementert i Ruby. Scriptet er skrevet for OS X-miljø, men koden bør være relativt lesbar og enkel å porte til ditt eget favorittspråk og utviklingsmiljø.

Happy testing!

Eksempel:

# Command line command which launches all unit tests
RUN_TESTS_CMD = "mvn clean test"

# Pick up any changes in files matching this filepath
FILES_TO_MONITOR = "**/*.java"

# Determine test outcome by scraping test output for #telltale signs of failure or exceptions

def test_failed?(test_output)
  return (test_output["FAIL in"] != nil) # Any 'FAIL in' strings in test result indicates failure
end

def exception_occurred?(test_output)
  return (test_output["EXCEPTION in"] != nil)
end

# Indicate test state by turning the background color of the test terminal
# a different color - yellow red og green. Currently uses Mac AppleScripts, but could be
# an audible signal, lava lamp, or anything else instead.

def indicate_tests_running
  `osascript bin/autotest/make-term-yellow`
  puts "\n\n\n----------------------------------"
  puts "TESTRUN STARTED #{Time.now}"
  puts "----------------------------------\n\n\n"
end  

def indicate_test_success(description)
  `osascript bin/autotest/make-term-green`
  puts description
end  

def indicate_test_errors(description)
  `osascript bin/autotest/make-term-red`
  puts description
end  

$monitored_files = {} # Stores the last changed time of each file    

def files_changed? # Check if any files have been touched/saved since last check
  file_changed = false;  

  Dir[FILES_TO_MONITOR].each do |filepath|
    if(!File.new(filepath).ctime.eql?($monitored_files[filepath]))
      file_changed = true;
      $monitored_files[filepath] = File.new(filepath).ctime
    end
  end  

  return file_changed
end  

def run_test
  indicate_tests_running
  result = `#{RUN_TESTS_CMD}`  #Run the tests, pipe resulting console output back
  display_results(result)
end    

def display_results(testOutput)
  if test_failed?(testOutput)
    indicate_test_errors("SOME TEST(S) FAILED\n"+testOutput)
  elsif exception_occurred?(testOutput)
    indicate_test_errors("EXCEPTIONS OCCURRED\n"+testOutput)
  else
    indicate_test_success("ALL TESTS SUCCEED\n"+testOutput)
  end
end  

def test_loop
  while true
    if files_changed?
      run_test
    end
    sleep(1) #seconds between each poll for file changes
  end
end  

test_loop # Start testing!

• Bug rapport: “Administrative kostnader” skal fjernes: Når vi beregner totalkostnaden til et veiprosjekt, inkluderer vi kostnaden av nyanlegg, ombygging, bruer og administrative kostnader. Når vi demonstrerte applikasjonen til brukerne våre, husket de plutselig at administrative kostnader er sjelden i bruk og burde egentlig fjernes fra applikasjonen. Endringen var enkel og det er usannsynlig at en bedre analyse på forhånd hadde kommet fram til samme konklusjon. Dette er den type feilrapport vi liker å få.
• Bug rapport: Ikke-effektuerte utbetalinger skal telle mot totalt tilgjengelige midler: Når vi sjekket om det var tilstrekkelige midler for å utføre en utbetaling, glemte vi å ta med de utbetalingene som var registrert, men ikke utført enda. Tilstandsovergangen av utbetalinger fra registrert til godkjent til utført var litt mer kompleks enn vi hadde forventet, og enhetstestene sjekket ikke tilstrekkelig med varianter. Vi burde ha funnet denne feilen med enhetstestene våre, men dersom vi aldri får feil av denne typen, kan det være en indikasjon på at vi er for nøye med testingen vår. Så feilen er helt grei. Spesielt ettersom konsekvensene for brukeren ikke var spesielt store
• Bug rapport: Perioder som starter i desember rapporterer IllegalArgumentException: Når vi beregnet neste måned, glemte vi å ta hensyn til at du kan ikke bare legge til én på månedsnummer. Neste måned etter desember er ikke måned 13! Dette var en slurvete feil og jeg tror den ble introdusert en gang når vi ikke parprogrammerte (fordi koden var så triviell, liksom!). Brukerne våre forstår at slike type feil kan skje, men vi må se nøyere på prosessen vår for å unngå slike feil i fremtiden.
• Bug rapport: Layout ser rotete ut i Internet Explorer: For å unngå noen tekniske problemer når vi skrev enhetstester for HTML’en vi produserte, fjernet vi midlertidig doctype-definisjonen fra webside-malene våre. Så glemte vi å putte definisjonen inn igjen (jada, et nytt eksempel der vi ikke parprogrammerte). Sidene så fortsatt fine ut i Chrome og Firefox, som utviklerne brukte for manuell verifisering. Men i Internet Explorer så websidene direkte kaotiske ut. Den tekniske konsekvensen av feilen var triviell, men feilen kunne lett ha vært unngått, dersom vi vi hadde testet med samme nettleser som brukerne våre. Noen av brukerne våre fikk dette håpløse førsteinntrykket av applikasjonen mens de hjalp oss å teste. Det var skikkelig flaut. Dette vil vi ikke at skjer igjen!

Det er litt vanskelig å definere hvilke bugs som gjør meg mest flau. Noen viktige faktorer er hvor vanskelig ville det vært for oss å unngå feilen og hvor stor konsekvens feilen har. Men andre faktorer påvirker også hvordan vi oppfatter en bug. Av feilene på lista over, så er den jeg er mest flau over kun en kosmetisk feil. Men siden dette var noen brukeres førsteinntrykk av applikasjonen, var det mye mer problematisk enn de særtilfellene vi ikke helt støttet.

Hva synes du gjør en feil mer eller mindre akseptabel?

Fokus på “hvorfor”, ikke “hvordan”

Hva forsøker denne testen å uttrykke:

Når en bruker registrerer en betaling med beløp “-1234567890″, så skal brukeren se en feilmelding

Hva med denne:

Når en bruker registrerer en betaling med et negativt beløp så skal brukeren få en passende feilmelding

Magiske tall, tekster og verdier i tester skjuler hva vi forsøker å spesifisere. Noen flere eksempler: “når en bruker utelater et eller flere påkrevde felter, så skal brukeren få en feilmelding knyttet til de manglende feltene”, “gitt at brukeren leverer en lottorekke med for få tall”.

Å koble slike tester mot systemet krever mer arbeid, spesielt de første gangene, men testene blir mye klarere etterpå. Og hovedformålet med en akseptansetest er at den er en spesifikasjon som kan diskuteres mellom prosjektet og omverdenen. Og da er det viktig å være klar. Noen ganger vil det virke svært vanskelig å automatisere forståelige spesifikasjoner. Da bør du huske at en god beskrivelse er mer verdifull enn en dårlig test.

Given-when-then

Noe av det første du lærer med tester er “bruk formen ‘gitt X, når Y, så Z’”. Men det er ikke alltid så klart hva X, Y og Z skal være. Tester består av tre typer steg:

• Arrange (oppsett, “given”): Beskriver tilstanden til systemet før testen starter. Typiske eksempler er “gitt at det eksisterer en bruker med utestående betalinger“, “gitt at tjenesten levert fra vår partner har registrert et varenummer” eller kanskje “gitt at det er en fredag” (du får vente til freddan). Avhengig av systemet og tilstanden vi beskriver, kan testen benytte disse stegene på forskjellige måter: Vi kan sette opp brukeren og betalingene i systemet, vi kan se på steget som en forutsetning som vi sjekker om er oppfylt, for eksempel ved å gjøre et søk mot tjenesten fra vår partner, vi kan forutsette, eller endog håpe at det er oppfylt og vi kan la steget kun være dokumentasjon, slik at når testen feiler, så vet vi noen ting vi kan verifisere manuelt, eller det kan være en ren løgn. Kanskje systemet er satt opp på en spesiell måte slik at det ikke er avhengig av ukedagen. Men vi har lyst til å dokumentere hvordan det hadde sett ut om det hadde vært “på ordentlig.”
• Act (utfør, “when”): Beskriver stimuli inn fra omverden. “Når brukeren registrerer en ny betaling,” “når klientsystemet sender en betalingsforespørsel med manglende kundeinformasjon”. Disse kan implementeres på flere måter i de fleste systemer: Et test av et web-grensesnitt kan simulere en klient med for eksempel webdriver, den kan gjøre et http-kall og direkte, eller testen kan bruke klassene som implementerer tjenesten direkte. For funksjonelle tester foretrekker jeg nesten alltid det siste. Det gjør at testene vil kjøre hundre ganger raskere, og vil som regel innebære mindre jobb. Husk: Det er ikke nødvendig å teste brukergrensesnittet på nytt for hver valideringsregel eller spesialtilfelle i applikasjonen din.
• Assert (sjekk, “then”): Beskriver hvordan systemet skal reagere på stimuli og hva tilstanden til systemet skal være etterpå. For eksempel “så skal brukeren få en feilmelding om at alle betalinger må være utført før en ny betaling kan registreres”, “så skal den nye betalingen ikke lagres i systemet.”

Veien fra testscript til spesifikasjoner

Når prosjekter først tar i bruk FitNesse er det veldig vanlig å se tester som ser cirka slik ut:

• Putt inn en kjempeliste med rader med en bråte kolonner inn i tabell A.
• Putt inn en ny kjempelist med rader etc i tabell B
• Send inn et kjempemessig XML dokument
• Sjekk at svaret matcher et nytt XML dokument

Dette er ikke en spesifikasjon – det er et testscript. Og det er ikke slike tester som gir verdi til et prosjekt. Men det er et sted å starte, for det krever ikke så veldig mye kreativitet. Og vi kan gjenbruke lærdommen fra slike tester. Men før det blir en hel skog av tester som dytter XML-dokumenter hit og dit, kan det være lurt å løfte testene opp på et mer logisk nivå:

• Gitt at det ikke eksisterer noen betalingsforespørsler
• Og en bruker er registrert
• Når brukeren sender inn en betalingsforespørsel med ett gitt problem
• Så skal brukeren få feilmeldingen en gitt feilmelding

I FitNesse-terminologi kan en slik test implementeres som en ColumnFixture. Det vil si: Hvert par av “problem” og “feilmelding” er en rad i en tabell. Slik kan vi uttrykke mange regler ved systemet klart og konsist.

Dersom du har startet å gå veien med testscript, er det ikke vanskelig å snu: For hver rad i den nye spesifikasjonen din skal du utføre alt det testscriptet ditt gjorde.

Jeg vil bruke jobben med akseptansetester til ikke bare å gjøre automatiske kjøringer av systemet mitt, men til å spesifisere og diskutere de egentlige kravene brukerne mine bryr seg om. Og dersom jeg må velge mellom tester som lar seg automatisere og spesifikasjoner som beskriver kravet, vil jeg alltid velge det siste.

Uten mer om og men, poster jeg en video her av hvordan jeg liker å jobbe med tester for å drive fram “kravene” til en applikasjon og refactoring for å forme designet til applikasjonen. Se spesielt rundt 11:30 minutter inn i videoen hvor jeg refactorer inn et regelmotordesign i en fungerende løsning.

Oppgaven kalles “Fizz buzz kataen”. Den går ut på å generere en sekvens av nummer der hvert tall som er delelig på 3 erstattes med “fizz” og alle tall som er delelig på 5 erstattes med “buzz”. Så starten blir “1, 2, fizz, 4, buzz, fizz, 7, 8, fizz, buzz, 11, etc.” Seks minutter inn i kataen endres kravet (og musikken!): Nå skal man kunne programmere inn hvilke erstatningsregler som gjelder. Som eksempel bruker jeg at “tall delelig med 2 skal erstattes med ‘coconut’ og tall delelig med 7 skal erstattes med ‘banana’”.

Takk til Emily Bache for inspirasjon til oppgaven.

Fizz buzz code kata av Johannes Brodwall på Vimeo.

Jeg bruker IntelliJ IDEA Community Edition på Windows Vista (!) til å løse oppgaven. Videoen er filmet med BB FlashBack Express (som er gratis), konvertert til AVI med Windows Media 1 codec og lastet opp til Vimeo.

Denne blogposten var originalt publisert på engelsk på min personlige blog.