Integrasjonstester til besvær

Har du jobbet med testdrevet utvikling en stund, så har du også støtt på integrasjonstester. Integrasjonstester er av natur uregjerlige beist som ikke kan rikkes på uten at minst èn av testene bryter, og man bruker ofte lang tid på både å forstå og rette testene – bare for at de skal bryte igjen to uker senere.

Mange påstår at de driver med TDD mens sannheten er at de fleste skriver DDT (Development Driven Testing). Koden kommer først, og man tilpasser testene til koden. Dette fører til to ting:

  • Koden blir ikke så dynamisk og lesbar som den burde bli
  • Man glemmer negative tester og tester ikke godt nok på grenseverdier.

Nå, si høyt det som skrives ut i konsollet

for (i=0; i<100; i++) {
  System.out.println(
    “Testing er ikke for å finne bugs i min kode, " +
    "men skal forbedre forståelsen for koden samt " +
    "forhindre feil under vedlikehold!”);
}

Men dette er om integrasjonstester. Når man tester integrasjon mot for eksempel en database, er det viktig å distansere seg fra unit-testing. Noen av de vanligste feilene er:

  • Feil nr. 1: Man tester CRUD-operasjoner. Vi vet at en database er meget dyktig på CRUD-operasjoner. Det er nettopp det den er laget for – å skrive, lese, oppdatere og slette data fra tabeller.
  • Feil nr. 2: Man tester tredjepartsfunksjonalitet. Det er ikke ditt ansvar å teste om en database kan lese og skrive data. Tredjepartsprodukter skal testes av respektive eier, ikke av de som bruker den.
  • Feil nr. 3: Man håndterer ikke feilsituasjoner, men bare tester om det virker.

Og det leder oss over på hva som virkelig er interessant ved integrasjonstesting: Hva er interessant å teste?

  • Først og fremst, test integrasjonen – at den ønskede modulen er til stede. Hva skjer i programmet mitt når den ikke er tilgjengelig?
  • Hva skjer når de dataene jeg ønsker å nå, ikke er tilgjengelig? Si at en overivrig DBA har endret passordet på brukeren, eller endret rettighetene?
  • Hva skjer om databasen eller tabellen min er slettet?
  • Hvilke feilsituasjoner/feilmeldinger kan jeg få fra databasen min? Er noen av disse håndtert i en unit-test, trenger jeg ikke å ta de med i integrasjonstestene.
  • Har jeg alle feltene jeg trenger, og får jeg dem på den strukturen jeg forventer? Dersom applikasjonen har full kontroll på databasen, kan også dette punktet håndteres med unit-tester i de fleste tilfellene.

Mantraet i all testing – både unit-testing og integrasjonstesting, er å påse at applikasjonen oppfører seg som forventet når feil oppstår, så skriv gode tester, og spør deg selv hva du ønsker å teste, hvilke feil som kan oppstå og hvordan kan man dekke dem.