JUnit - PowerPoint PPT Presentation

junit n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
JUnit PowerPoint Presentation
play fullscreen
1 / 28
JUnit
266 Views
Download Presentation
dawson
Download Presentation

JUnit

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. JUnit Don Braffitt http://www.radford.edu/dbraffitt/ Updated: 10-Jun-2011

  2. JUnit – Pocket Guide • JUnit Pocket Guide • By:Kent Beck • Publisher: O'Reilly Media, Inc. • Pub. Date: September 23, 2004 • Print ISBN-13: 978-0-596-00743-0 • 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); System.out.println(fixture.size( ));

  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’vewritten • 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 reportsdifferences

  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 thecreation of an error, the greater your chance of finding theerror 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 extraneousoverhead. • Easy to learn to write. Because our target audience forJUnit is programmers who are not usually professionaltesters, we would like to minimize the barriers to testwriting. • Quick to execute. Tests should run fast so we can runthem hundreds or thousands of times a day. • Easy to execute. The tests should run at the touch of abutton and present their results in a clear andunambiguous format. • Isolated. Tests should not affect each other. If the orderin which the tests are run changes, the results shouldn’tchange. • Composable. We should be able to run any number orcombination 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 notgenerally 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 itbegins to execute and return the world to its originalstate 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. JUnitImplementation • 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 • 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 • Subclass TestCase • Write new Assert classes • Write new Test Runner • Pre-built extensions • JUnitPerf • HttpUnit • JWebUnit and many others

  25. JUnit and Ant

  26. Running JUnit Standalone

  27. JUnit and IDEs

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