We believe unit testing server side components is going to get harder and harder in the future (unless something is done about it !). Even now, depending on the specifications for a given component model it is more or less easy. Sometimes it is even not feasible to test all kind of code.

将来的に、サーバ側コンポーネントの単体テストは、 (何か手を施さないかぎり) どんどん難しくなっていくと思います。 現在なら、与えられたコンポーネントモデルの仕様に依存しているので、 簡単です。 場合によっては、全ての種類のコードをテストすることは不可能です。

We believe that we will see more and more components in the future. By components we mean pieces of code that execute in a container. The container will provide more and more services for the components (like transactions, security, life cycle, persistence, interfaces - like web services -, logging, ...). The consequences will be :

将来、今よりももっと多くのコンポーネントが提供されると思います。 ここでは、コンポーネントは、コンテナで実行されるコードのかたまりを意味します。 コンテナは、コンポーネントに対し、益々多くのサービスを提供するようになるでしょう。 (トランザクション、セキュリティ、ライフサイクル、 頑強性、ウェブサービスなどのインタフェース、ログ、など) その結果、次のようになるでしょう :

• testing strategies that are not in-container, like Mock Objects will become less useful. Indeed, as the components will rely more and more on the container's services, the confidence that the tests will run well when deployed will decrease and the need for a solution that ensures the code will run correctly in it's environment will increase,
• Mock オブジェクトのような、内部コンテナでないテスト戦略は、 あまり有用ではなくなるでしょう。 実際に、コンポーネントは、どんどんコンテナのサービスに依存するようになっており、 配備されたら正常動作するだろうという確信はなくなっていき、 その環境でコードが正常動作することを確認するためのソリューションの要求が大きくなるでしょう。
• it will become more and more difficult to offer an in-container unit testing framework that lives outside the container.
• コンテナの外に存在する内部コンテナ単体テストフレームワークへの要求は、益々難しいものとなるでしょう。

上述の予想に従って、Cactus には 2 つの長期目標があります :

• Continue with the in-container approach as much as possible. It is a best try effort in order to provide tests in which you can have a good confidence,
• 内部コンテナによるアプローチを可能な限り長く続けてきます。 とても信頼できるテストを提供できるように、 最善を尽くして続けていきます。
• However, we believe the only satisfactory and long term solution is to include (unit) testing APIs as part of the container specifications. This could be done in the form of a SPI (Service Provider Interface) against which a generic unit testing framework could be plugged, thus leaving the implementation details to an external framework and only providing maybe a generic and simple implementation. Thus, the goal of Cactus will be to help specify needed container API/SPI for unit testing, i.e. create an additional service of the container : a "unit-testing service" (in addition to the existing Security, Transaction, Life Cycle, ... Services). As Cactus and Tomcat projects are both hosted on Jakarta it might be a good test ground for this kind of work. Of course, the first step would be to convince Tomcat developers that unit testing (and testing in general) is indeed a need to be addressed in the container itself. The ultimate goal will be reached when this new API/SPI is accepted and become a de jure standard. It would then be time to think about integrating it into the Servlet Specifications (or other components -like EJBs - specifications). Agreed, this far-streched at the current time but it is the Cactus vision !
• しかしながら、唯一の満足できる長期的な解決策は、 コンテナの仕様の一部として(単体)テストAPIを含めることです。 これは、 汎用のテストフレームワークがプラグインできる事に対して、 ですから、実装の詳細は外部のフレームワークに委ね、 提供だけを行うことが、汎用的で単純な実装なのです。 従って、Cactus のゴールは単体テストのために必要なコンテナAPI/SPIの仕様策定を援助すること、 即ち、 (既存のセキュリティ、トランザクション、ライフサイクルなどのサービスに加えて) コンテナの追加サービス : "単体テストサービス" を作ることです。 Cactus と Tomcat は共に Jakarta で行われているので、 この種の作業を行うには、良いテスト環境なのかもしれません。 もちろん、 最初のステップは、 単体テスト(および一般にテスト) が実際にコンテナ自身の要求として位置付けられるように、 Tomcat 開発者に便宜を図ることです。 究極の目標は、 この新しい API/SPI が受容され制定規格となった時に、 達成されるでしょう。 その時が、 サーブレット仕様 (あるいは他の EJB などのコンポーネント) への統合を考える時期なのです。 確かに、現時点では随分先の話ですが、 これが Cactus のビジョンなのです。