1. Don Braffitt http://www.radford.edu/dbraffitt/ Updated: 26-Mar-2013
JUnit
Don Braffitt
Updated: 26-Mar-2013

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

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

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

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

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

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

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

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

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

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

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

13. JUnit - Testing Exceptions

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

15. JUnit Implementation
JUnit converts the test class into a TestSuite

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

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

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

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

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

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

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

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

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

25. JUnit and JWebUnit
import static org.junit.Assert.*; import org.junit.After; import org.junit.Before; import org.junit.Test; import static net.sourceforge.jwebunit.junit.JWebUnit.*; public class TestBlueJ {          public void prepare() {         setBaseUrl("     }     public void test1() {         beginAt("index.html");         assertTitleEquals("BlueJ - Teaching Java - Learning Java");     }

26. JUnit and JWebUnit
    public void test2() {         beginAt("download/download.html");         assertTitleEquals("BlueJ - Download");     }     public void test3() {         beginAt("index.html");         assertLinkPresentWithExactText("home");     }     public void test4() {         beginAt("index.html");         assertLinkPresentWithExactText("about BlueJ");     }

27. JUnit and JWebUnit
    public void test5() {         beginAt("index.html");         assertLinkPresentWithExactText("resources");     }     public void test6() {         beginAt("index.html");         clickLinkWithText("Parade");         assertTitleEquals("BlueJ");         setTextField("q", "3.0.7");         submit();         assertTitleEquals("Search Results – BlueJ");     }     public void close() {         closeBrowser();     } }

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

29. JUnit – New with JUnit 4 Based on annotations – not naming conventions
More flexible initialization and cleanup
Timeouts
Exception tests
Requires Java 5 or later The theme of JUnit 4 is to encourage more developers to write more tests by further simplifying JUnit. To this end, we have followed NUnit's lead in identifying tests by annotation instead of subclassing and naming conventions. -- Kent Beck on the JUnit mailing list, June 14, 2005