En test-klasse består gjerne av mange test-metoder og hver test-metode vil typisk først rigge opp en eller flere instanser og så teste at disse oppfører seg som forventet. Ta test-klassen for Counter
-klassen som eksempel:
public class CounterTest extends junit.framework.TestCase { public void testCounter() { Counter counter = new Counter(1, 3); assertEquals(1, counter.getCounter()); } public void testGetCounter() { Counter counter = new Counter(1, 3); assertEquals(1, counter.getCounter()); counter.count(); assertEquals(2, counter.getCounter()); counter.count(); assertEquals(3, counter.getCounter()); } public void testCount() { Counter counter = new Counter(1, 3); assertTrue(counter.count()); assertFalse(counter.count()); } }
Her har vi tre test-metoder, som hver oppretter en instans og tester oppførselen til henholdsvis konstruktøren, getCounter
og count()
. Vi ser at alle rigger opp like instanser og dersom dette hadde vært mer enn én linje kode, så hadde det vært greit å samle denne koden i en egen hjelpemetode, f.eks. kalt riggInstanser, som kalles i begynnelsen av hver test-metode:
public class CounterTest extends junit.framework.TestCase { private Counter counter = null; private Counter riggInstanser() { counter = new Counter(1, 3); } public void testCounter() { riggInstanser(1, 3); ... } public void testGetCounter() { riggInstanser(1, 3); ... } public void testCount() { riggInstanser(1, 3); ... } }
Siden dette er et relativt vanlig tilfelle har JUnit-rammeverket innebygget støtte for en slik hjelpemetode. Denne er deklarert som protected void setUp() throws Exception
i TestCase-klassen og kalles automatisk av JUnit rammeverket før hver test-metode. Test-klasser som ønsker å rigge opp instanser, eller på annen måte gjøre forberedelser før testene, kan redefinere setUp()
-metoden med ønsket innhold. Hver test-metode er sikret at instansene er ferdig rigget opp, og siden dette skjer på nytt for hver test-metode, så kan disse herje fritt med instansene uten å tukle det til for de andre test-metodene. Koden over kan dermed skrives om slik:
public class CounterTest extends junit.framework.TestCase { private Counter counter = null; @Override protected void setUp() { counter = new Counter(1, 3); } public void testCounter() { ... } public void testGetCounter() { ... } public void testCount() { ... } }
I noen tilfeller vil det som rigges opp av setUp()
-metoden også måtte rigges ned, for ikke å forsøple systemet testene kjøres på. Det kan f.eks. være praktisk å opprette noen temporære datafiler i setUp()
-metoden, og da må de jo fjernes etterpå. Det vil ikke være særlig ryddig å gjøre dette i test-metodene selv, siden en da må bruke try/finally
for å sikre at det skjer uansett utfall av testen. Derfor støtter JUnit-rammeverket en tearDown()
-metode, som kalles automatisk etter at hver test-metode er kjørt, uansett om testen ble avbrutt eller ikke. Som for setUp()
er denne definert i TestCase
-klassen og egnet for redefinering. I tilfellet over er ikke en slik metode nødvendig (hver test-metode kjøres på en ny instans av CounterTest), men en test-klasse med tearDown()
-metode kunne sett slik ut:
public class CounterTest extends junit.framework.TestCase { private Counter counter = null; @Override protected void setUp() { counter = new Counter(1, 3); } @Override protected void tearDown() { counter = null; } public void testCounter() { ... } public void testGetCounter() { ... } public void testCount() { ... } }
Sider om Enhetstesting med JUnit: