Junit Notes

Author:Holyfair Chen
E-mail:plutocsj@hotmail.com

***************************
=  Something about JUnit  =
***************************
1.JUnit (junit.org) is open source software, released under IBM’s Common Public
  License Version 1.0
 
2.Three kinds of Runners to choose: junit.textui.TestRunner ;
                                    junit.awtui.TestRunner ;
                                    junit.swingui.TestRunner ;
                                   
3.TestCase: Setup() ---> testXXX()------>tearDown()

4.You can add some TestCases to one TestSuite and run them together.The TestRunner
  starts the tests by calling the TestSuite’s run(TestResult)method.
   
5.A TestResult advertises:  A test has been started (startTest; see E).
     A test has failed (addFailure; see figure 2.10).
     A test has thrown an unexpected exception
        (addError; see figure 2.10).
     A test has ended (endTest; see figure 2.10).
 
6.The TestCases in a TestSuite can be run orderly.Also you can write your own TestSuites
  to run those TestCases randomly.
 
7.Junit can also test private class methods.(using the PrivilegeAccessor.java)

8.junit.extension package: 1.test result report;
      2.use ActiveTestSuite to deal with multiThread Test;
      3.ExceptionTestCase:if no Exception then report Error;
      4.RepeatTest;
      5.TestSetup: the public enviroment initialize;
      ...

==================================================================================
==================================================================================

*********************************
= Automating JUnit =
*********************************

1.You can run Junit from Ant, Maven,and Eclipse;

2.Eclipse: download Eclipse-Junit-plugin,put it in the folder "{Eclipse-HOME}/plugin/";

3.ant: pre:cp the junit.jar to "{ANT_HOME}/lib"
 a example:
  <!-- =============Test Targets=========== -->
  <target name="test" depends="compile">
   <mkdir dir="${target.report.dir}"/>
   <junit printsummary="yes" haltοnerrοr="no" haltonfailure="no" fork="yes">
    <formatter type="plain" usefile="false"/>
    <formatter type="xml"/>
    <test name="test.Mock.TestMainSuite" todir="${target.report.dir}"/>
    <classpath>
      <pathelement location="WEB-INF/classes/src"/>
      <path refid="compile.classpath"/>
    </classpath>
   </junit>
  </target>

  <!-- ============Report Targets========== -->
  <target name="report" depends="test">
   <mkdir dir="${target.report.dir}/html"/>
   <junitreport todir="${target.report.dir}">
    <fileset dir="${target.report.dir}">
     <include name="TEST-*.xml"/>
    </fileset>
    <report todir="${target.report.dir}/html"/>
   </junitreport>
  </target>
 
4.Also, you can run test in Eclipse with ant-build way.

5.JUnit best practices: same package, separate directories;

==================================================================================
==================================================================================

**********************************
=  Testing strategies  =
**********************************
----------------------------------------------------------------------------------
【Stubbing】
definition:
     A stub is a portion of code that is inserted at runtime in place of
 the real code, in order to isolate calling code from the real implementation.
 The intent is to replace a complex behavior with a simpler one
 that allows independent testing of some portion of the real code.

advantage:
 1.Stubs are a mechanism for faking the behavior of real code that may exist
   or that may not have been written yet.Stubs allow you to test a portion
   of a system without the other part being available.
 2.They usually do not change the code you’re testing but instead adapt to
   provide seamless integration.

Tools mentioned:
 1. Using "Jetty" as an embedded server;

comments:stubbing a web server, the filesystem, a database, and so on

----------------------------------------------------------------------------------
【Mock Objects】  (isolate a method call to another class,used as Trojan horses)
    (outside-the-container testing)
definition:
       A mock object (or mock for short) is an object created to stand in for
  an object that your code will be collaborating with. Your code can call
  methods on the mock object, which will deliver results as set up by your
  tests.
 
Technology mentioned:
 1. Refactoring: <1>easy method refactoring technique
   <2>refactoring by using a class factory

When to use:
 * Real object has non-deterministic behavior;
 * Real object is difficult to set up;
 * Real object has behavior that is hard to cause;
 * Real object is slow;
 * Real object has a UI;
 * Test needs to query the object, but the queries are not available in the real
   object (for example, “was this callback called?”)
 * Real object does not yet exist

comments:
 1.The MockObjects project(http://www.mockobjects.com)provides some ready-made
 mock objects for stantard JDK APIs. The mocks usually have expectations built
 in.In addtion, the MockObjects project contains some reusable expectation
 classes that you can use in your own mocks.
 
 2.present several open source frameworks that automatically generate ready-to-use
 mocks for your classes  make it a pleasure to use the mock-objects strategy.
  <1>Mockrunner
   Mockrunner is a lightweight framework for unit testing applications
          in the J2EE environment. It supports Struts actions and forms,
          servlets, filters and tag classes. Furthermore it includes a JDBC
           test framework. The JDBC test framework can be used standalone
            or in conjunction with MockEJB to test EJB based applications.
  <2>MockEJB ,EasyMock ,Mock Objects MockMacker,DynaMock,etc;

 3.mock-object generation tool:
  MockMacker can be the Eclipse Plugin!!!
 

----------------------------------------------------------------------------------
【Cactus】  (In-Container Testing)
  URL concerned:http://jakarta.apache.org/cactus/
  **Mock objects and Cactus are both valid approaches.**

 Executing the tests using 【Cactus/Jetty integration】
 Code example:
 public static Test suite()
 {
  TestSuite suite = new TestSuite("All tests with Jetty");
  suite.addTestSuite(TestCaseExendXXXTestCase.class); //( xxx can be Servlet,
  //Jsp, or Filter
  )
  return new JettyTestSetup(suite);
 }

Life cycle of a Cactus test:
 execute begingXXX()---it. The beginXXX method lets you pass information to the redirector
              |
 open the proxy-redirector connection
              |
 create the server-side TestCase instance
              |
 call setUp, testXXX, and tearDown on the server side
              |
 execute endXXX ---This method is used so that your tests can assert additional results from the
 code under test.
              |
 Gathering the test result

Drawbacks of in-container testing:
 1. Specific tools required;
 2. Longer execution time;
 3. Complex configuration.

 

==================================================================================
==================================================================================

*********************************
= Testing components =   (J2EE components)
*********************************

【【When to use Cactus, and when to use mock objects】】 
 At this point, you must be wondering whether to use Cactus or mock objects to
 test your servlets and filter. Both approaches have advantages and disadvantages:
   The main difference is that Cactus performs not only unit tests but also
  integration tests and, to some extent, functional tests. The added benefits
  come at the cost of added complexity.
   Mock-object tests are usually harder to write, because you need to define
  the behavior of all calls made to the mocks. For example, if your method
  under test makes 10 calls to mocks, then you need to define the behavior
  for these 10 calls as part of the test setup.
   Cactus provides real objects for which you only need to set some initial
  conditions.
   If the application to unit-test is already written, it usually has to be refactored
  to support mock-object testing. Extra refactoring is generally not
  needed with Cactus.
 A good strategy is to separate the business-logic code from the integration code
 (code that interacts with the container), and then:
   Use mock objects to test the business logic.
   Use Cactus to test the integration code.

Other components testing can be know from the book: <Junit in Action>
----------------------------------------------------------------------------------
【servlets & filters】

----------------------------------------------------------------------------------
【JSPs & taglibs】

----------------------------------------------------------------------------------
【database application】

----------------------------------------------------------------------------------
【EJBS】

----------------------------------------------------------------------------------

【Struts】