As is stated on the Cactus goals page, the intention is to explore as much as possible in the realm of unit testing of server side java code ...

Cactus の目標のページで位置付けたように、 目的はサーバー側 java コードの単体テストの領域をできる限り広げることです。

This brings a bad news and a good one ... The bad one is that the TODO list is likely to keep growing or at least have a respectable size ... The good one is that there will be work for everyone ... :-)

これには、良いことも悪いこともあります。 悪いことは、ToDoリストが大きくなりつづけようとしたり、 少なくともかなりのサイズになることです。 良いことは、皆さんのために仕事があることです。

If you are interested in participating, send an email on the Cactus mailing list stating your interest and you'll be enrolled right away ... We're always looking for help ! Don't be put off if in the "Volunteer" column there is already a person listed. On the contrary, the more person that participate in a given task, the better (like in pair programming, several sets of eyes are always better than one!). However you'll need to sync. with these others persons but this is easily done by posting to the mailing-list.

参加に興味がある方は、 Cactus メーリングリストにメールください。 興味のある分野を判断し、すぐに役割を与えられるでしょう。 何時でも、私達は協力を必要としています。 もし、表の"ボランティア" の列に既に名前があったとしても、 思いとどまらないでください。 それどころか、一つの与えられた作業に多くの人が参加するほど、 ((XPの)ペアプログラミングにおいて、 一人よりも二人の目の方が必ず良いように) 良くなるのです。 これら他の人たちと作業の同期を取る必要がありますが、 メーリングリストに投稿することにより、これは簡単にできます。

The game has just begun ... !

ゲームは始ったばかりです。

Move all documentation to docbook and cocoon2 and generate PDF containing full Cactus documentation. Note: I still need to find out how to make Cocoon2 generate errors during generation of doc. so that the Ant build reports an error and stops upon finding one. / 全てのドキュメントを docbook および cocoon2 に移行し、 Cactus ドキュメント全体が含まれるような PDF を生成します。 メモ : Cocoon2 がドキュメント生成時にエラーを発生させる方法を調べる必要があります。Ant のビルドがエラーを報告し、発見した場所で停止させるためです。 Add a tutorial for building Cactus from the source distribution. / ソースディストリビューションから Cactus をビルドするチュートリアルの追加 Write a tutorial that explains how to use Cactus to do unit testing of JSP, i.e. only test the JSP itself and not the controller part and the model (only test the View in an MVC model). This is done by using mock implementations of java beans used in the JSP to unit test, set these java beans in the testXXX() method of a cactus test and then assert the result of the JSP executing in the endXXX() method. / Cactus で JSP の単体テストを行う方法を説明するチュートリアルの記述。 即ち、コントローラー部やモデルではなく、 JSP 自身のみをテストするもの(MVCモデルのビューのみのテスト)。 これらの java beans を Cactus テストの testXXX() メソッドの中に置き、 endXXX() メソッドの中で JSP を実行した結果のアサーションを行うような JSP の単体テストで使われる java beans の mock 実装を用いて実現されます。 (できれば FAQ に) Struts クラスの単体テスト法を解説したドキュメントの追加 StrutsTestCase プロジェクト参照)

All tasks that are related to building Cactus in general.

一般的に Cactus のビルドに関する全ての作業

Configure all supported containers with authentication so that they pass the Cactus unit tests (done for Tomcat 3.x + Tomcat 4.x). / (Tomcat 3.x + Tomcat 4.x では終っているが) Cactus 単体テストに成功するように、 サポートしている全てのコンテナが 認証を行えるような設定 Finalize support for Enhydra 3.1.1. There are some errors upon starting the enhydra server and the testOut() method is failing. Need help from Enhydra experts to go forward. / Enhydra 3.1.1 のサポートの終了。 Enhydra サーバーの起動時に幾つかエラーがあり、 testOut()メソッドが失敗します。 進めるには Enhydra のエキスパートの助けが必要です。 Add the Ant scripts for JBoss 2.x w/Tomcat provided by Jeffrey Madynski (jmadynski@food.com) on the jakarta-commons mailing list (Subject "[cactus] Using Cactus with JBoss-2.2.1 with Embedded Tomcat"). The scripts need to be reworked so that the deployed test war is deployed within the target output directory and not to where JBoss/Tomcat is installed. / jakarta-commons メーリングリストで Jeffrey Madynski(jmadynski@food.com)により提供された (件名 "[cactus] Using Cactus with JBoss-2.2.1 with Embedded Tomcat")、 JBoss 2.x + Tomcat 用Ant ビルドファイルの追加。 そのビルドファイルは、 JBoss/Tomcat がインストールされた場所ではなく、 配備されるテストの war ファイルが、 target 出力ディレクトリに配備されるように、 修正作業が必要です。 Add support for Form-based authentication. / Form ベースの認証のサポート Refactor/redesign the Cactus client side so that it can accept several kinds of protocol injectors (it now only supports HTTP). The idea is to be able to add first JMS so that Message-Driven Beans or simply JMS listeners can be unit tested. / 幾つかの種類のプロトコル生成器を扱えるように、 Cactus クライアント側のリファクタリング/再設計。 (現在では、HTTP のみをサポート) メッセージ起動の Bean や簡単な JMS リスナーが単体できとできるように、 そのアイディアは、最初に JMS に加えることが出来ることです。 Add methods that are called before and after each test, but on the client side (i.e. before the beginXXX() and endXXX() methods). They would act the same way as setUp() and tearDown() but on the client side. They could be named init() and destroy(), or maybe we should rather rename the existing setUp() and tearDown() and have something consistent like : setUpClient(), setUpServer(), tearDownClient() and tearDownServer() ? / クライアント側ではなく、 テスト実行の前後に呼ばれるメソッドの追加 (即ち、beginXXX()の前、および endXXX() メソッドの後) それらは、 クライアント側ではなく、 setUp() や tearDown() と同じ方法で振舞います。 それらの名前は、 init() および destroy()にするか、あるいは、 既存の setUp() と tearDown() の 名前を変更して、 setUpClient()、setUpServer()、 tearDownClient() 、tearDownServer()、 と一貫性を持たせた方がいいかもしれません。 Provide support for generating Session cookies and URL Sessions (URL rewriting). A description of the mechanism has been posted in thread "How does cactus simulate a session" on the Cactus user mailing list. Thanks to Kyle W. Willkomm. / セッションクッキー生成、および、 URL セッション(URL 書き換え)生成のサポート。 このメカニズムの解説は Cactus メーリングリストの "How does cactus simulate a session" のスレッドに投稿されました。 Kyle W. Willkomm に感謝します。 Add EJB Redirectors so that unit testing of code that require an EJB is facilitated. For example, let's imagine you need to test that an object that has been put in the JNDI tree by a servlet can be retrieved by an EJB. These are not unit tests per see but rather integration tests, which is Cactus favorite domain. Also these redirectors could be used to directly unit tests EJB whithout requiring a servlet environment (at the current time, you need to call your EJB from a Servlet/JSP/Filter Redirector, which is fine for certain tests but not needed for others. / EJB を必要とするコードの単体テストが容易になるよう、 EJB リダイレクタの追加。 例えば、 サーブレットにより JNDI ツリーに置かれたオブジェクトが、 EJB によって取り出せるか、 テストをしなければならないとしましょう。 これらは一見、単体テストではなく、むしろ、 Cactus の得意分野である結合テストです。 また、これらのリダイレクタは、 サーブレットを必要とせずに、 直接 EJB を単体テストするのにも使われます。 (現状では、自分の EJB を Servlet/JSP/Filter リダイレクタから呼び出す必要があります。これは、あるテストでは良いのですが、他では必要ないものです) Consider using Commons Logging Wrapper as it provides seamless support for No Log, Log4J, LogKit and JDK 1.4 logging. / ログが無い場合、Log4J、LogKit、および JDK 1.4 のログを 区別無くサポートするために、Commons Logging Wrapper の利用を考慮します Add an EJB sample application to demonstrate how to perform EJB unit testing (the tutorial that explains the process will be part of Cactus 1.2 but the inclusion of the sample will be delivered in a subsequent release as it involves some changes in the build process). / EJB 単体テストを行う方法をデモする EJB サンプルアプリケーションの追加. (この手順を説明したチュートリアルは Cactus 1.2 の一部ですが、 ビルド手順に変更があったので、 サンプルに入っているものは後のリリースで配布されました。) Consider moving from HttpURLConnection to Commons HttpClient. This will solve the problem of asserting code that returns an error response code. Note: this has been fixed in JDK 1.3.1 I believe for HttpURLConnection but as we're already using HttpClient for handling cookies (because the JDK does not seem to provide any API for that). Review JDK 1.4's HttpURLConnection to check if the JDK is making any progress in this area. In term of design, isolate the implementation with an interface so that different implementation can be plugged in without affecting any other business classes. / HttpURLConnection から Commons HttpClient への移行の検討。 エラーコードを返すようなコードのアサーションで起きる問題を解決します。 メモ: 恐らく、これは JDK 1.3.1 において、HttpURLConnection に関して修正されました。 しかし、既に、クッキーを扱うために HttpClient を使っていたのです。 (何故なら JDK は、それに関する API を何も提供していない様子だからです。) この分野において JDK に進捗があったか、 JDK 1.4 の HttpURLConnection をレビューします。 設計の観点から、 他のどんなビジネスクラスにも影響が無いように、 異なる実装がプラグインできるように、 実装とインタフェースを独立させます。

探求のアイディア/Ideas to explore ...

Create a new package org.apache.cactus.extensions for putting extensions to Cactus Test Cases. The first extension would be an extension that runs a bunch of test at the same time, thus spawing several threads in the container in order to discover bugs [Note: We would have to correct the name under which Cactus test results are stored in the application context so that it is unique per test case]. We would need to create a org.apache.cactus.extensions.ParallelServletTestCase. The constructor would take some parameters, such as the number of parallel threads to spawn, ... Idea suggested by Michael Rimov. / Cactus テストケースの拡張を置くための、 新しいパッケージ org.apache.cactus.extensions の作成。 最初の拡張は、同時に複数のテストを実行する拡張でしょう。 それにより、バグを見つけるために、 コンテナ上で幾つかのスレッドが生成されます。 [メモ: テストケース毎にそれらが重ならないように、 Cactus のテスト結果がアプリケーションコンテキストに保存される正しい名前を付けなければなりません。 ] org.apache.cactus.extensions.ParallelServletTestCase を作成する必要があるでしょう。 コンストラクタは、 生成する並行スレッドの数といった引数を取るでしょう。 アイディアは Michael Rimov により提案されました。 Use XDoclet with Cactus to better provide continuous integration. It could be used to automatically generate web.xml files, automatically generating test cases from methods to test, ... / より良い継続的な統合を提供するための、 Cactus での XDoclet の利用。 これは、 web.xmlファイルの自動生成や、 テストすべきメソッドよりテストケースの自動生成を行うために用いられます。 Integration to Netbeansorg.apache.cactus.extensions in general and especially integration with the Netbeans XTest module. / 一般的な Netbeansorg.apache.cactus.extensions との統合、 および、特に Netbeans XTest モジュールとの統合 Evaluate the use of AspectJ for writing Cactus test cases. / Cactus テストケースの記述に AspectJ の利用を検討 Help Cactus users test multipart/form-data. At least explain how to do it. Some idea: use cos.jar (from http://www.servlets.com/cos/index.html) to read multipart/form-data on the server side. Now we still need to provide a mechanism to easily send multipart/form-data on the Cactus client side. The best solution would be to use HttpClient but we need to check if it has this feature or if it can be added. Submitted by Gunnar Ole Skogen. / ユーザーの複数部分からなるフォームデータ のテストのサポート。 少なくとも、やり方について説明します。 幾つかのアイディア: サーバ側で複数部分からなるフォームデータを読み込みために、 cos.jar (http://www.servlets.com/cos/index.htmlより)を使用。 今でも、Cactus クライアント側で複数部分からなるフォームデータを簡単に送るメカニズムの提供を必要としています。 最適解は、HttpClient を使うことですが、 この機能を持っているか、追加可能かなど検証しなければなりません。 これは、 Gunnar Ole Skogen により提案されました。