Start Unit Testing with JUnit 4.4

1. Eben Hewitt, Kevin Williams 12.19.07 Start Unit Testing with JUnit 4.4

2. Presentation Overview Benefits of Unit Testing Using JUnit 4.4 Incorporating JUnit into Your Projects Writing Good Unit Tests Writing Testable Code

3. Why Now? Meant to work within Agile SOA Project Need to change shared code Easier than ever

4. Why Unit Test? Facilitates Change Less fear to update shared code Regression Confidence Immediate and Certain Feedback--it�s fun! Deadline Confidence Integration is Easier Helps Document Shows Proper System Use Helps Cope with Complexity Allows us to explore further automation

5. Why Unit Test? part. 2 Don�t ask �What code do I write to solve my problem?� Better to ask: �How will I know that I actually solved my problem?� Cost of bugs is reduced We don�t buy when it sounds good--only when we need it Requirement for SOA and Java projects in 2008

6. Challenges at DTC �Java Can�t Add� Store System Invoice Mismatches Money with Unit Test instead of BigInteger Lots of shared code Tires.com Cart/Packages Java Language Changes (Generics) Environment Changes (Linux)

7. Limitations of Unit Testing It�s slower to write also tests unless you want your code to work Tests can be wrong--who will police the police? Tests can be incomplete Does not eliminate need for QA

8. Using JUnit 4.4 Free, open-source Current version 4.4 Built into IDEs

9. Writing Basic Unit Tests Use @Test, no extending TestCase Use JUnit static methods assertTrue, assertEquals Example: @Test public void testTrim(){ assertEquals(�XXX�, trim(� XXX �); }

10. More JUnit Features @Before and @After Run at every test method execution No more setup(), tearDown() @BeforeClass and @AfterClass Only invoked once @Ignore

11. Parameterized Tests Allows you to run the same test with different data To Use: Add @RunWith(Parameterized.class) Add a public static method that returns a Collection of data. Each element of the collection must be an Array of the various parameters used for the test. Add a public constructor that uses the parameters

12. Suites Specify an execution order To use, add @Suite to an empty class import org.junit.runner.RunWith; import org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses({SomeTest.class}) public class AllTests { }

13. Putting It All Together Eclipse Demo

14. Incorporating JUnit into Your Projects

15. Preparing to Write Tests Make a Java source directory for test classes: <project>/src/test Put Junit-4.4.jar on your classpath Create a package named <package-you�re-testing>, plus �test�: com.dte.common.util.test Create your test class named <class-you�re-testing>, plus �Test�: StringUtilitiesTest.java

16. Preparing Your Project Copy compile-test and run-test targets into your build.xml from Common Make sure your dte.properties is up to date with junit.jar entry Add <path id=�test.classpath�> from common build.xml Add a mkdir for your test classes directory Add a mkdir for the reports directory Make your build process dependent on the run-test target Make it run every time you build

17. Running Your Tests In NetBeans hook up the �Test� target to the run-test target In Eclipse, run the run-test target

18. Testing Exceptions Your code makes decisions and has side-effects based on exceptions you throw. Test that they work correctly: @Test(expected=ParseException.class) public void testParseTireSizeException(){ parseTireSizeStr(�xxx�, new TireSize()); }

19. Writing Good Unit Tests

20. Where to Start with Your Code Any static utility method must have test Make negative and exception tests Business models with equals and hashcode Shared projects as time permits DTE Common Anything with Business Rules Transformations Parsing, regex, data cleanup, XML/Config Reads Start Simple Don�t worry about HTTPUnit, Cactus, Swing, etc at first

21. Good JUnit Tests Only test the interface exposed to the outside world Test behavior Keep them flexible and test what matters. BAD: expect 748 rows returned for StoreType==1 GOOD: check row.storeType == 1 for every returned row Test Exceptions too Test that �something is true� but also that �not-something is false�

22. Good JUnit Tests pt 2 Maintain and comment like first-class citizens Give your tests meaningful names BAD: parseDate GOOD: testParseDateValid, testParseDateInvalid, testParseDateException Use @Before and @After for databases Test in isolation Tests must NOT be dependent on each other Do not pollute your code base

23. On the Web Cactus for server-side (JSP, servlet, EJB) extends Junit http://jakarta.apache.org/cactus/ Struts Test Case http://strutstestcase.sourceforge.net/

24. Writing Testable Code Write the test first Encourages thinking of your Dream Client Which encourages you to think about interfaces Which encourages you to defer choices It�s hard to make tests pass when your class is incomplete. Implement: Equals & Hashcode toString Data and Behavior Together Separate Comparator<T>

25. Writing Testable Code pt 2 Encourages you to separate concerns Your classes should separate concerns Encourages you to use Object Parameter pattern Don�t define more than a very few params Provides validation when implementation changes Use interfaces, factories Err gracefully

26. Tests Expose Leaking... Data from a Class Classes from a package Layers Non-isolated external dependencies (I/O, database) Tight Coupling Lack of Encapsulation Need for Factories (test object or real object returned)

27. SOA Testing JUnit Tests plus CASA Tests NetBeans 6 Demo

28. Load Testing Kevin�s Thread Load Utility WebStart-able! Easy to use! Customize for your project! Load Utility Demo

29. Questions Download from Wiki: This presentation Demo source code We�re here to help!