1. Testing code COMP204

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

3. 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 ;

4. 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();

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

6. 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

7. Junit import static org.junit.Assert.*; assertEquals(a,b); assertArrayEquals(x,y); … Annotations: –@Test –@Before –@After –@Ignore –@Test(expected = RuntimeException.class) –@Test(timeout = 100)

8. 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; }

9. 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); }

10. 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