Testing code

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