Ville du ha brukt notepad til å skrive kode ?
Selvsagt (forhåpentligvis) ikke. Vi bruker IDE til programmering fordi det gir en sikrere og raskere prosess. Moderne IDE-er inneholder et arsenal av verktøy. En av disse er code templates. Jeg skal her gå igjennom hvordan man kan bruke de innebygde code templatene eller endre disse slik at de passer perfekt. Man kan også lage nye selv. Jeg vil her bruke Eclipse og Java som et eksempel. Code templates finnes derimot i flere IDE-er (som for eksempel InteliJ og Netbeans) og kan også benyttes på samme måte i andre programeringsspråk enn java.

Bruk de innebygde code templatene

Eclipse kommer med mange innebygde templates. Disse listes opp under Preferences-Java-Editor-Templates. For å aktivere templaten i koden trykker du “Ctrl-Space-Space”.

Skal du opprette en junit-test (og det gjør du vel en del ganger?) finnes det en template for å dette. Denne ser slik ut:

Her lages det en metode annotert med test. org.junit.Assert importeres statisk. Og cursoren settes inne i metoden. Det opprettes også en variabel (testname). Dette gjør at brukeren skriver rett etter genereringen fylles inn der.

Det er fullt mulig å editere på templatene hvis de ikke passer helt. Dersom man for eksempel bruker fest assert så trenger man ikke statisk import av org.junit.Assert. Det er bare å slette den delen.

Ta deg tid til å ta en titt på de innebygde templatene. Det er antgelig flere ting du gjør ofte som det finnes templates som gjør denne jobben lettere.

Lag dine egne templates

Man kan også lage sine egne templates. Her skal vi ta for oss to eksempler.

Template for equals metode

Vi skal her se på en template for en eguals metode (Jada, det finnes mange andre måter for å enkelt lage en equalsmetode, men dette er et eksempel)

Minst 99% av alle equalsmetoder starter med å sjekke at objektet er av riktig type. Siden klassenavnet varierer fra klasse til klasse (duh), bruker vi en variabel “enclosing_type”. Denne erstates med navnet på klassen vi er i. I tillegg caster vi deretter objektet til den aktuelle typen. Det er i tillegg lagt på en nullsafe equalsmetode som kan brukes til å sjekke de aktuelle atributtene. Vi har også tatt med en gyldig (men ikke veldig bra) implementasjon av hashCode slik at man oppfyller kontrakten mellom equals og hashcode.

Template for å generere en factory metode

Mange ganger er det nyttig å opprette en klasse med en statisk metode. Følgende template hjelper deg på vei her :

Som vi ser brukes det mye av de samme teknikkene som i equals templaten. Det som er nytt er bruken av variable. Variable er felt som brukeren kan editere på umiddelbart etter å ha kjørt templaten. Her bruker vi dette til å redigere på variabelnavnet (som jo varierer mye fra klasse til klasse). Feltnavnet brukeren skriver inn oppdateres tre steder:

1. I feltnavnet
2. I parameteren til metoden
3. I tilordningen på begge sider av likhetstegnet.

Disse templatene er bare eksempeler. I et hvert domene finnes det noe som gjøres mange ganger og er nesten likt. Tenk deg om. Antagelig finnes det noe code templates kan hjelpe deg med. Hvis du vil kopiere noen av templatene fra eksemplene finner du dem og noen til her.

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!

Lykke til med ditt testbare prosjekt!

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.