Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
titleTestkode for konstruktøren
linenumberstrue
Counter counter = new Counter(01, 23);
assertEquals(01, counter.getCounter());	// sjekk om returverdi er 1

Counter-instansen som lages i første linje er ment å telle fra 0 til (og med) 2. Andre linje sjekker om getCounter() returnerer den forventede verdier 0. Generelt sjekker kall til assertEquals om argumentene er like, hvor det første argumentet er fasiten og det andre den faktiske (retur)verdien. For å sjekke det andre utsagnet må vi utføre et par runder med kall til getCounter() og count(), og sjekke returverdien mot fasiten for hvert kall:

Code Block
titleTestkode for count()-metoden
linenumberstrue
assertEquals(true, counter.count());
assertEquals(12, counter.getCounter());
assertEquals(false, counter.count());
assertEquals(23, counter.getCounter());

Hvordan får vi så kjørt koden over, slik at vi får testet om Counter-koden er korrekt i henhold til kravene? Koden må først legges inn i test-metoder i en test-klasse, og så må den kjøres ved hjelp av JUnit-rammeverket. En test-klasse må arve fra JUnit sin TestCase-klasse og test-metodene må være void-metoder uten argumenter, med navn som begynner med "test", slik:

Code Block
titleTest-klasse for Counter-klassen
linenumberstrue
import org.junit.TestCase;
public class CounterTest extends junit.framework.TestCase {
   public void testCounter() {
      Counter counter = new Counter(01, 23);
      assertEquals(01, counter.getCounter());	// sjekk om returverdi er 1
      assertEqualsassertTrue(true, counter.count());				// sjekk om returverdi er true
      assertEquals(12, counter.getCounter());	// sjekk om returverdi er 2
      assertEqualsassertFalse(false, counter.count());				// sjekk om returverdi er false
      assertEquals(23, counter.getCounter());	// sjekk om returverdi er 3
   }
}

I Eclipse er det nå bare å høyreklikke på testklassen og velge Run as->JUnit Test. Da vil alle test-metodene i test-klassen bli kjørt og resultatet blir vist i et eget JUnit panel:

Image Added

Meldingen forteller at sjekken vår i linje 6 i CounterTest.java har avdekket en feil, counter.getCounter() returnerte 0, mens den forventede verdier var 1! Hvis vi ser nærmere på koden, så ser vi at vi har glemt å initialisere pos-variabelen til start-verdien. Derfor startet den på 0 istedenfor 1. Dersom vi endrer linje 4 i Counter.java til this.pos = start; og kjører på nytt, så skal feilen være fikset:

Image Added

Der avdekket vi en annen feil (programmet stopper på den første feilen i hver test-metode), i sjekken vår i linje 9 fikk vi true, men fasiten var false. Problemet denne gang er at count()-metoden returnerer true også den siste gangen den øker telleren. Vi må endre litt på logikken, slik:

Code Block
titleEndelig versjon av Counter-klassen
linenumberstrue
public class Counter {
   private int pos, end;
   public Counter(int start, int end) {
      this.pos = start;
      this.end = end;
   }
   public int getCounter() {
      return this.pos;
   }
   public boolean count() {
      if (pos < end) {
         this.pos = this.pos + 1;
      }
      return this.pos >=< end;
   }
}

Denne gangen kjører testen uten feil og vi har (større) grunn til å tro at Counter-klassen er implementert i henhold til kravene.

Image Added

Noen avsluttende kommentarer:

  • I dette eksemplet har vi kun testet klassen vår med ett sett test-data og dette er sjelden nok til å finne alle feil. Dersom vi f.eks. hadde instansiert med new Counter(0, 2), så hadde ikke den første feilen blitt oppdaget, siden default-verdien tilfeldigvis var riktig! Derfor er det lurt å teste med sannsynlige, usannsynlige og gjerne tilfeldige verdier.
  • Det er vanlig å strukturere koden i mange små test-metoder, som hver tester kun ett krav. I dette tilfellet kunne vi laget to test-metoder, f.eks. testCounter() for å teste konstruktøren, og testCount() for å teste count()-metoden. Ved kjøring vil begge test-metodene bli utført og vi kan avdekke flere feil på en gang. Det vil dessuten ofte være praktisk å skrive private hjelpemetoder for å gjøre test-metodene ryddigere.

Les mer om JUnit-testing:

  • setUp- og tearDown-metodene
  • Testing av unntak med JUnit
  • test-samlinger (TestSuite)