Testing code COMP204

How to? “manual” –Tedious, error-prone, not repeatable “automated” by writing code: –Assertions –Junit

Assertions “manually” if (! check()) { throw new RuntimeException(“…”); } Better: use “assert” command assert check(); Will only be checked if enabled: -ea assert check42(a) : “check42 failed for “ + a ;

Assertions continued Use in methods to check preconditions: assert (parameter1 != null); Or post-conditions before returning: assert (stack.size() == oldSize+1); Or class-invariants at the start and end of public methods: assert integrity();

Junit Unit testing implements tests for “units” in separate classes that usually mirror the original class structure: –BoundedStack.java –BoundedStackTest.java

Unit tests Check all public methods Can even be used as specifiation (e.g. in TDD - test driven development), written *before* the code they test Run after a every code change Have someone else write unit tests

Junit import static org.junit.Assert.*; assertEquals(a,b); assertArrayEquals(x,y); … Annotations: = RuntimeException.class) = 100)

How good are the tests Code coverage: –Is every line executed at least once? –Borderline cases (e.g. +/- 1) public int sumAndSort(Integer[] a) { int sum = 0; for(Integer e: a) sum += e; Arrays.sort(a); return sum; }

Two different “full cover” tests public void someTest() { assertEquals(6, sumAndSort(new Integer[]{3,1,2})); } public void betterTest() { Integer[] a = new Integer[]{3,1,2}; assertEquals(6, sumAndSort(a)); assertArrayEquals(new Integer[]{1,2,3}, a); }

Jumble: mutation testing Open source, Honour’s project of Tin Pavlinic, supervised by Prof.John Cleary (ReelTwo), a few years ago Mutates the byte-code of a class, then checks whether the unit-tests pick up the changes