1 / 10

Testing code

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

hermione-mendez
Télécharger la présentation

Testing code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related