JUnit Don Braffitt Updated: 10-Jun-2011

JUnit – Pocket Guide JUnit Pocket Guide By: Kent Beck Publisher: O'Reilly Media, Inc. Pub. Date: September 23, 2004 Print ISBN-13: Pages in Print Edition: 90

JUnit – Overview Created by Kent Beck and Erich Gamma Java open source framework for test-driven development Appeals to programmers using an agile (iterative and incremental) programming method such as Extreme Programming which advocates frequent releases in short development cycles

JUnit - Automating Tests Consider this starting point Now consider this initial testing effort List fixture= new ArrayList( ); // fixture should be empty Object element= new Object( ); fixture. add(element); // fixture should have one element List fixture= new ArrayList( ); System.out.println(fixture.size( )); Object element= new Object( ); fixture. add(element); System.out.println(fixture.size( ));

JUnit – Automating Tests Now do output only if a failure is detected Now build a new method to handle the output List fixture= new ArrayList( ); System.out.println(fixture.size( ) == 0); Object element= new Object( ); fixture. add(element); System.out.println(fixture.size( ) == 1); void assertTrue(boolean condition) throws Exception { if (! condition) throw new Exception("Assertion failed"); }

JUnit – Automating Tests Finally, use the new AssertTrue method List fixture= new ArrayList( ); assertTrue(fixture.size( ) == 0); Object element= new Object( ); fixture. add(element); assertTrue(fixture.size( ) == 1);

JUnit - Why Test? JUnit does the following: Runs tests automatically Runs many tests together and summarizes the results Provides a convenient place to collect the tests you’ve written Provides a convenient place for sharing the code used to create the objects you are going to test Compares actual results to expected results and reports differences

JUnit – Why Test? Win-win-win programming practice A win for me in the short term A win for me in the long term A win for my teammates and customers

JUnit – Why Test? Defect Cost Increase (DCI) The sooner you test after the creation of an error, the greater your chance of finding the error and the less it costs to find and fix the error

JUnit – Goals Simultaneously tests should be: Easy to write. Test code should contain no extraneous overhead. Easy to learn to write. Because our target audience for JUnit is programmers who are not usually professional testers, we would like to minimize the barriers to test writing. Quick to execute. Tests should run fast so we can run them hundreds or thousands of times a day. Easy to execute. The tests should run at the touch of a button and present their results in a clear and unambiguous format. Isolated. Tests should not affect each other. If the order in which the tests are run changes, the results shouldn’t change. Composable. We should be able to run any number or combination of tests together. This is a corollary of isolation.

JUnit – Goals There are two main clashes between these constraints: Easy to write versus easy to learn to write. Tests do not generally require all the flexibility of a programming language, especially not an object language. Isolated versus quick to execute. If you want the results of one test to have no effect on the results of another test, each test should create the full state of the world before it begins to execute and return the world to its original state when it finishes.

JUnit - Fixtures setUp() tearDown() Move variable parts of setUp() to test methods No convenient support for suite-level setup

JUnit - Testing Exceptions

JUnit Implementation Consider a test case class with two test methods public class EmptyTest extends TestCase { List empty= new ArrayList( ); public void testSize( ) { assertEquals(0, empty.size( )); } public void testIsEmpty( ) { assertTrue(empty.isEmpty( )); }

JUnit Implementation JUnit converts the test class into a TestSuite

JUnit Implementation When the TestSuite is run, it runs each of the EmptyTest in turn Each runs its own setUp( ) method, creating a fresh ArrayList for each test

JUnit Implementation To run the test method itself, JUnit uses reflection to find the method named in fName and invokes it This trick is called Pluggable Selector in the Smalltalk world You can’t look at the code to decide whether a function is invoked, you have to look at the data values at runtime. Pluggable Selectors in JUnit make writing the tests much simpler

JUnit Implementation Summary One test-case class results in a two-level tree of objects when the tests are run Each test method works with its own copy of the objects created by setUp( ) The result is tests that can run completely independently

JUnit’s API Five main classes or interfaces Assert - A collection of static methods for checking actual values against expected values Test - The interface of all objects that act like tests TestCase - A single test TestSuite - A collection of tests TestResult - A summary of the results of running one or more tests

JUnit - Test-First Programming Part of test-driven development White-box tests for whole specification Incremental tests as you gradually add specified functionality Tests are expected to fail since you don’t have complete functionality to test

JUnit - Stubs Stubs don’t faithfully reproduce the behavior of the intended object Always better to have at least one test case failing while the stub is in place

JUnit - Other Uses for Tests Debugging Tests Learning an API with Tests Documenting Assumptions with Tests Cross-Team Tests

Story of JUnit Kent Beck 1994 Smalltalk testing framework (3 classes 12 methods) Eric Gamma 1997 With Kent Beck, built most of JUnit on a plane in 3 hours

Extending JUnit Add your own extensions Subclass TestCase Write new Assert classes Write new Test Runner Pre-built extensions JUnitPerf HttpUnit JWebUnit and many others

JUnit and Ant

Running JUnit Standalone

JUnit and IDEs

JUnit - Test Infection Write lots of tests Runs your tests often Learn the design skills necessary to write tests that are simple and run fast Start sharing your skills with others