Step 1: Imports첫 번째 단계 : 임포트(import)

여러분의 테스트 클래스에 다음의 임포트(import)들을 포함하셔야 합니다(캑터스가 JUnit 을 테스트를 호출하기위한 클라이언트측 어플리케이션(application) 처럼 사용하기 때문에 junit.framework.* 이 필요합니다). You need to include the following imports in your test class ( junit.framework.* is needed because Cactus uses JUnit as the client side application for calling the tests):

import org.apache.cactus.*;
import junit.framework.*;

Step 2: Extend a Cactus TestCase class or reuse a JUnit TestCase 두 번째 단계 : 캑터스 테스트케이스 클래스를 상속 받거나 JUnit 테스트케이스를 재사용하기

public class TestJUnitTestCaseWrapper extends TestCase
{
    public static Test suite()
    {
        ServletTestSuite suite = new ServletTestSuite();
        suite.addTestSuite(TestJUnitTestCaseWrapper.class);
        return suite;
    }

    public void testXXX()
    {
    }
}

Step 3 (optional): setUp() and tearDown() methods

As in JUnit, you can define a setUp() and a tearDown() methods. They are executed respectively before and after each test case. However, whereas in JUnit they are executed on the client side, in Cactus they are executed on the server side. It means that you will be able to access the Cactus implicit object (these are the objects from the API as described in Step 2) within them. In other words, you'll be able to do things such as putting a value in the HTTP Session prior to calling the test cases, etc.

As in JUnit, the setUp() and tearDown() methods are optional.

Step 4 (optional): begin() and end() methods

begin(...) and end(...) methods are the client side equivalent of the setUp() and a tearDown() methods (see previous step). They are called on the client side, before and after every test.

The begin() and end() methods are optional.

Step 5: testXXX() methods

As in JUnit, the main method for a test is the testXXX() method. The difference being that these methods are executed in the container with Cactus. Each XXX test case must have a testXXX() method defined.

In your testXXX() methods you will:

• instantiate the class to test (you can also factor this instance out and define is as a class instance variable),
• setup any server-side domain object (like putting a variable in the Http session, ...). Indeed, the Cactus test case class that you have extended in Step 2 has several instance variables (they are the different API objects mentioned in Step 2) that it has initialised with valid objects. Depending on the test case class that you have extended these variables are request (of type HttpServletRequest), config (of type ServletConfig for ServletTestCase or of type FilterConfig for FilterTestCase), ... (see the "Testcase Specific Details" Step below),
• call the method to test,
• perform JUnit standard asserts (asserts(..), assertEquals(...), fail(...), ...) to verify that the test was successful

For example:

public void testXXX()
{
    // Initialize class to test
    SampleServlet servlet = new SampleServlet();

    // Set a variable in session as the doSomething() method that we are testing need
    // this variable to be present in the session (for example)
    session.setAttribute("name", "value");

    // Call the method to test, passing an HttpServletRequest object (for example)
    String result = servlet.doSomething(request);

    // Perform verification that test was successful
    assertEquals("something", result);
    assertEquals("otherValue", session.getAttribute("otherName"));
}

Step 6 (optional): beginXXX() methods

For each XXX test case, you can define a corresponding beginXXX() method (optional). You will use it to initialize HTTP related parameters (HTTP parameters, cookies, HTTP headers, URL to simulate, ...). You will be able to retrieve these values in your testXXX() by calling the different API of HttpServletRequest (like getQueryString(), getCookies(), getHeader(), ...).

The signature of the begin method is:

public void beginXXX(WebRequest theRequest)
{
  [...]
}

where theRequest is the object (provided by Cactus) that you use to set all the HTTP related parameters.

The full description of all the HTTP related parameters that you can set can be found in the javadoc for the WebRequest interface. You should also check the examples provided as part of the Cactus distribution.

The beginXXX() methods are executed on the client side, prior to executing testXXX() on the server side and thus, do not have access to any of the class variables that represent API objects (their values are null)

Step 7 (optional): endXXX() methods

For each XXX test case, you can define a corresponding endXXX() method. You will use this method to verify the returned HTTP related parameters from your test case (like the returned content of the HTTP response, any returned cookies, returned HTTP headers, ...).

For versions of Cactus up to v1.1, the signature of the end method is:

public void endXXX(HttpURLConnection theConnection)
{
  [...]
}

... and some helper methods to extract the response content and cookies were provided in the AssertUtils class (see javadoc).

However, beginning with Cactus 1.2, this signature has been deprecated. There are now 2 possible signatures for the end method, depending on whether you need to perform sophisticated checks on the content of what is returned or not. For complex checking, we have integrated with the HttpUnit framework. See the HttpUnit tutorial for the end method signatures and a full description.

The endXXX() methods are executed on the client side, after executing testXXX() on the server side and thus, do not have access to any of the class variables that represent API objects (their values are null)