Junit Notes

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

***************************
***************************
1.JUnit (junit.org) is open source software, released under IBM’s Common Public

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
 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;
4.RepeatTest;
5.TestSetup: the public enviroment initialize;
...

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

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

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

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" haltonerror="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.

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
* Real object does not yet exist

1.The MockObjects project(
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
 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】

0 0