Dear Wiki user, You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.
The "HowToDevelopUnitTests" page has been changed by SteveLoughran. http://wiki.apache.org/hadoop/HowToDevelopUnitTests?action=diff&rev1=3&rev2=4 -------------------------------------------------- Here's the short list of traps one need to be aware and not to develop yet another JUnit v3 test case - * YES, new unit tests HAVE to be developed for JUnit v4 + * YES, new unit tests HAVE to be developed for JUnit v4. No patches which add v3 test case classes will be approved. * DO NOT use {{{junit.framework}}} imports * DO use only {{{org.junit}}} imports * DO NOT {{{extends TestCase}}} (now, you can create your own test class structures if needed!) @@ -49, +49 @@ The final tactic is half-way between JUnit 3.x and the JUnit 4 styles; the Hadoop team is yet to come down against it, though they reserve the right. + == Effective Assertions == + + 1. Use the JUnit assertions, not the Java {{{assert}}} statement. + 1. In equality tests, place the expected value first + 1. Give assertions meaningful error messages. + + === Bad === + + {{{ + /** a test */ + @Test + public void testBuildVersion() { + Namenode nn = getNameNode(); + assertNotNull(nn); + NamespaceInfo info = nn.versionRequest() ; + assertEquals(info.getBuildVersion(),"32"); + } + }}} + + + === good === + + {{{ + /** + * Test that the build version is OK + */ + @Test + public void testBuildVersion() { + Namenode nn = getNameNode(); + assertNotNull("No namenode", nn); + NamespaceInfo info = nn.versionRequest() ; + assertEquals("Build version wrong", "32", info.getBuildVersion()); + } + }}} + + When any of the equals assertions fail, the error text includes the text inserted in the assertion, and the expected and equals values. You don't need to explicitly include them. For all assertions, providing hints as to what is wrong is good. + == Logging == All Hadoop test cases run on a classpath which contains commons-logging; use the logging APIs just as you would in Hadoop's own codebase @@ -64, +101 @@ } }}} + Don't go overboard in logging at info level, as it can be buffered in the test runners (especially the XML one) and lead to out of memory problems. Log the details at debug level which can then be turned on for specific tests causing problems. + == Exception Handling in Tests == - All test methods can declare that they throw {{{Throwable}}}. There is no need to catch exceptions and wrap them in JUnit {{{RuntimeException}}} instances. + Test methods can declare that they throw {{{Throwable}}}. There is no need to catch exceptions and wrap them in JUnit {{{RuntimeException}}} instances. === Bad === + {{{ @Test - public testCode() { + public void testCode() { try { doSomethingThatFails(); catch(IOException ioe) { @@ -81, +121 @@ }}} === good === + {{{ @Test - public testCode() throws Throwable { + public void testCode() throws Throwable { doSomethingThatFails(); } }}}
