1 / 29

Start Unit Testing with JUnit 4.4

Presentation Overview. Benefits of Unit TestingUsing JUnit 4.4 Incorporating JUnit into Your ProjectsWriting Good Unit TestsWriting Testable Code. Why Now?. Meant to work within AgileSOA ProjectNeed to change shared codeEasier than ever. Why Unit Test?. Facilitates ChangeLess fear to update

salena
Download Presentation

Start Unit Testing with JUnit 4.4

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

More Related