The Cactus tests are started by running a JUnit Test Runner (For explanations on how JUnit works see the JUnit web site). As pictured in figure 1, you need to have the following jars and classes in your client side classpath :

Cactus のテストは JUnit の Test Runner を実行することにより、 起動されます。 (JUnit 仕組みについての説明は、 JUnitウェブサイト をご覧ください。) 図 1 に示した通り、 クライアント側クラスパスに次の jar ファイルを置かなければなりません :

• junit.jar : obviously this is needed for the JUnit Test Runner and because the Cactus XXXTestCase classes extend the JUnit org.junit.framework.TestCase class.
• junit.jar : これが JUnit の Test Runner のために明らかに必要です。 何故なら、Cactus XXXTestCase クラスは JUnit の org.junit.framework.TestCase クラスを拡張するからです。
• cactus.jar : well, this is the Cactus jar containing all Cactus classes,
• cactus.jar : そう、これは全ての Cactus のクラスを含んでいる Cactus jar ファイルです。
• your test classes : these are your test classes that extend the Cactus XXXTestCase classes,
• 自分のテストクラス : これらは、Cactus の XXXTestCase クラスを 拡張した自分のテストクラスです。
• servlet.jar or j2ee.jar : these are the Servlet API / J2EE API interfaces. This is needed on the client side classpath because your test cases extend one or several of XXXTestCase which use class variables that are Servlet / J2EE objects (HttpSevletRequest, PageContext, ...). You can get this jar either from your servlet engine or from the Sun Web Site ( Servlet download page or J2EE download page).
• servlet.jar or j2ee.jar : これらは Servlet API / J2EE API インターフェースです。 これらはクライアント側のクラスパスに置いてある必要があります。 何故なら、 自分のテストケースは、一つあるいは幾つかの Servlet / J2EE オブジェクト (HttpSevletRequest、PageContextなど) であるXXXTestCase を拡張したものだからです。 この jar ファイルは、 インストールしたサーブレットエンジンや、 Sun ウェブサイト ( Servlet ダウンロードページ または J2EE ダウンロードページ) で得ることができます。
• httpclient.jar : needed for Cactus Cookie handling.
• httpclient.jar : Cactus が Cookie を扱うのに必要です。
• log4j.jar (optional) : only needed when you want Cactus to output debugging information on the client side.
• log4j.jar (optional) : Cactus にクライアント側でデバッグ情報を出力させたい場合にのみ必要です。
• httpunit.jar, Tidy.jar and xerces.jar (optional) : only needed if you wish to use HttpUnit in your endXXX() methods (see the HttpUnit Howto tutorial). The 3 jars mentioned above are part of the HttpUnit distribution.
• httpunit.jar, Tidy.jar and xerces.jar (optional) : 自分の endXXX() メソッド中で、 HttpUnit を使いたい場合にのみ必要です。 (HttpUnit Howto チュートリアルをご覧ください) 上述の 3 つの jar ファイルは HttpUnit ディストリビューションに含まれています。
• aspectjrt.jar : AspectJ runtime jar.
• aspectjrt.jar : AspectJ ランタイム jar ファイル

If you have the habit of using class variables for the classes to test (as opposed to declaring them within the testXXX() method), you'll also need to put your classes under test in the client side classpath.

テストしたいクラスのために、クラス変数を使う習慣がある場合 (testXXX() メソッド中でそれらを宣言する別の方法に対して)、 クライアント側クラスパスにテスト中のクラスを置かなければなりません。

In addition to the above mentionned jars and classes, you will also need to put the cactus.properties configuration file in your classpath (because it is a java properties file). Details are described in the Config Howto tutorial).

上述の jar およびクラスに加えて、 cactus.properties 設定ファイルをクラスパスに置かなければなりません。 (何故ならこれは java のプロパティファイルだからです。) 詳しくは 設定 Howto チュートリアルに書かれています。

In theory you would also need to put the log_client.properties properties file in your classpath. However a default one is provided in cactus.jar (and thus is on the classpath as cactus.jar is itself in the classpath !).

理論的には、 log_client.properties プロパティファイルもクラスパスに置かなければなりませんが、 デフォルトの物が cactus.jar にあります。 (従って、cactus.jar がクラスパスにあるので、 このファイルもクラスパスにあることになります。)

The server side part is a webapp. It can be packaged as a .war file or as expanded war. It should have the following structure, which will ensure that the classpath is correct :

サーバー側の部分はウェブアプリケーションです。 これは、.war ファイル、あるいは war を解凍したものとしてパッケージ化されています。 クラスパスが正しいか確認するためには、 次に示すようなディレクトリ構造でなければなりません :

• WEB-INF/lib/cactus.jar : the Cactus main jar,
• WEB-INF/lib/cactus.jar : Cactus のメインの jar ファイル
• WEB-INF/lib/junit.jar : this is needed because the Cactus XXXTestCase extends the JUnit org.junit.framework.TestCase class.
• WEB-INF/lib/junit.jar : Cactus XXXTestCase は、 JUnit の org.junit.framework.TestCase を拡張するため、これが必要となります。
• WEB-INF/classes/<your test classes> : obviously as their testXXX() methods will get executed in the container.
• WEB-INF/classes/<自分のテストクラス> : 明らかに、 その中の testXXX() メソッドがコンテナ上で実行されるので
• WEB-INF/classes/<your classes under test> : will be called by your test classes.
• WEB-INF/classes/<テストを行うクラス> : テストクラスにより呼び出されます
• WEB-INF/lib/log4j.jar (optional) : only needed when you want Cactus to output debugging information on the server side.
• WEB-INF/lib/log4j.jar (オプション) : Cactus にサーバー側にデバッグ情報を出力させたい場合にのみ必要です。

If you have several webapps that use cactus you may be tempted to place the cactus.jar in your container's shared library folder. However, this approach will not work in many cases because code in a shared location (cactus) cannot access code in a specific webapp (your test cases). This restriction makes sense since you would not want com.foo.EvilClass in webapp A to conflict with com.foo.EvilClass in webapp B.

Cactus を使った幾つかのウェブアプリケーションがあるとき、 コンテナ共有のライブラリフォルダに cactus.jar を 置きたくなることがあるかもしれませんが、 この方法では多くの場合動作しません。 なぜなら、 共有場所にある(cactus の)コードが特定のウェブアプリケーション(あなたのテストケース)のコードを参照できないからです。 ウェブアプリケーション A の com.foo.EvilClass が、 ウェブアプリケーション B の com.foo.EvilClass と競合させたくないために、 この制限は意味があります。

In theory you would also need to put the log_server.properties configuration file in your classpath. However a default one is provided in cactus.jar (and thus is on the classpath as cactus.jar is itself in the classpath !).

理論的には、 log_server.properties 設定ファイルも自分のクラスパスに置く必要がありますが、 デフォルトのものが cactus.jar で提供されています。 (従って、cactus.jar自身がクラスパスにあるので、 そのファイルもクラスパスにあるということです。)