|
Last update : July 6 2002
Doc for : v1.3
Cactusについて
Cactus とは
ニュース
変更履歴
特徴/開発状況
目標
ロードマップ/ToDo
協力者
協力者募集
Cactus ユーザ
テスト済環境 ...
ライセンス
ダウンロード
ダウンロード
ドキュメント
Cactus の仕組み
さぁ始めよう
モック対コンテナ
Javadocs
└Javadocs
よくある質問
Howto ガイド
クラスパス Howto
設定 Howto
アップグレードHowto
テストケース Howto
セキュリティHowto
Ant Howto
HttpUnit Howto
サンプル Howto
EJB Howto
IDE Howto
JUnitEE Howto
サポート
Bug DB
メーリングリスト
その他
名前の由来
ロゴコンテスト
参考文献
アクセス状況
└WebAlizer
開発者向け
CVS
コード規約
ビルドの結果
|
| はじめに/Introduction |
This tutorial explains how to write a test case, using Cactus. There
are several types of test cases : test cases for writing servlet
unit tests, test cases for writing taglib unit tests and test cases
for writing filter unit tests. We will first cover the principles
which are generic to all test cases and then we will dive into
the details specific to each test case.
本チュートリアルでは、Cactus を使ったテストケースの作成法について説明します。
テストケースには様々なタイプがあります :
サーブレット単体テストを記述するためのテストケース、
タグライブラリ単体テストを記述するためのテストケース、
フィルター単体テストを記述するためのテストケースなどです。
まず最初に、全てのテストケースにおいて一般的である原理について述べます。
そして次に、個々のテストケースに特有なことについて詳しく掘り下げていきます。
 |
In order to help writing test case we highly suggest to have a look
at the examples provided as part of the Cactus distribution. Also,
all the best practices for JUnit also applies to Cactus test cases
as they are in essence JUnit test cases.
|
 |
テストケースの書き方について理解しやすくするために、
Cactus ディストリビューションの一部として配布されるサンプルに目を通しておく事を強くお勧めします。
また、最適な JUnit の練習は全て、JUnit テストケースの本質として、
そのまま Cactus テストケースに適用できます。
|
|
| 一般的な原則/General principles |
To write a test case, please follow the steps defined below.
テストケースを記述するには、下に定義した手順に従ってください。
| ステップ 1 : インポート/Step 1 : Imports |
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 文を含めなければいけません。
(Cactusは、呼び出しテストのためのクライアント側アプリケーションとして
JUnit を使っているので、junit.framework.* が必要となります。) :
import org.apache.cactus.*;
import junit.framework.*;
|
|
| ステップ 2 : Cactus TestCase クラスの拡張/Step 2 : Extend a Cactus TestCase class |
Now, we need to create a class (our test class) that extends one of
Cactus test cases, depending on what we are testing :
さて次に、自分がテストしたい事に応じて、
Cactus テストケースの一つを拡張したクラス(自分のテストクラス)を作成しなければなりません。:
-
ServletTestCase : extend this class
for writing tests for unit testing code that uses Servlet API
objects (HttpServletRequest,
HttpServletResponse, HttpSession,
ServletConfig, ServletContext, ...),
like Servlets or any java classes which have methods that
manipulates Servlet API objects. For example :
public class TestSampleServlet extends ServletTestCase
{
|
-
ServletTestCase :
サーブレットや Servlet API オブジェクトを操作するメソッドを持った
java クラスといった、
Servlet API オブジェクト
(HttpServletRequest,
HttpServletResponse, HttpSession,
ServletConfig, ServletContext, ...)
を使った単体テストコードを記述するために、このクラスを拡張します。
例は次のようになります :
public class TestSampleServlet extends ServletTestCase
{
|
-
JspTestCase : extend this class for
writing tests for unit testing code that uses JSP API objects
(PageContext, JspWriter, ...), like
Taglibs or any java classes which have methods that manipulates
JSP API objects. For example :
public class TestSampleTag extends JspTestCase
{
|
-
JspTestCase :
タグライブラリや、JSP API オブエクとを操作するメソッドを持つ
java クラスのような JSP API オブジェクト
(PageContext, JspWriter, ...)
を使った単体テストコードを書くために、
このクラスを拡張します。
例は次の通りです :
public class TestSampleTag extends JspTestCase
{
|
-
FilterTestCase : extend this class
for writing tests for unit testing code that uses Filter API
objects (FilterChain, FilterConfig,
HttpServletRequest, HttpServletResponse,
...), like Filters or any java classes which have methods that
manipulates Filter API objects. For example :
public class TestSampleFilter extends FilterTestCase
{
|
-
FilterTestCase :
フィルターや、Filter API オブジェクトを操作するメソッドを持つ
java クラスのような
Filter API オブジェクト
(FilterChain, FilterConfig,
HttpServletRequest, HttpServletResponse,
...) を使った単体テストコードを書くためには、
このクラスを拡張します。例は次の通りです :
public class TestSampleFilter extends FilterTestCase
{
|
|
| ステップ 3 : 標準 JUnit メソッド/Step 3 : Standard JUnit methods |
As in a normal JUnit test case, define the following standard JUnit
methods :
標準 JUnit テスト−ケースのように、
次の標準 JUnit メソッドを定義します :
-
A constructor with a single parameter (it is the test name),
-
引数を 1 つ(これはテスト名です)持つコンストラクタ
-
A
main() method in which you start a JUnit test
runner if you want your test to be executable,
-
自分のテストを実行形式にしたい場合、
JUnit test runner を起動する
main() メソッド
-
A
suite() method to list the tests that should
be executed by your test class
-
テストクラスで実行されるべきテストの一覧を得るための
suite() メソッド
For example :
例 :
public TestSampleServlet(String theName)
{
super(theName);
}
public static void main(String[] theArgs)
{
junit.swingui.TestRunner.main(new String[] {TestSampleServlet.class.getName()});
}
public static Test suite()
{
return new TestSuite(TestSampleServlet.class);
}
|
|
| ステップ 4 (オプション) : setUp() および tearDown() メソッド/Step 4 (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.
JUnit のように、setUp() および
tearDown() メソッドを定義できます。
それらは各々、テストケースの前と後で実行されます。
しかしながら、JUnit においては、これらはクライアント側で実行されますが、
それに対し、Cactus では、これらはサーバー側で実行されます。
暗黙的な Cactus オブジェクト
(これらはステップ 2 で述べられている API からのオブジェクトです)
の内部へアクセスできることを意味します。
言い換えれば、テストケースを呼び出す前に、
HTTP セッションにおいて値を設定する、などといった事ができるわけです。
As in JUnit, the setUp() and tearDown()
methods are optional.
JUnit のように、
the setUp() および tearDown()
メソッドはオプションです。
|
| ステップ 5 : testXXX() メソッド/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.
JUnit のように、テストの主要なメソッドは、
testXXX() メソッドです。
違いは、これらのメソッドはコンテナ上で、
Cactus と共に実行されるということです。
個々の XXX テストケースに対して、
testXXX() メソッドが定義されている必要があります。
In your testXXX() methods you will :
自分のtestXXX() メソッドにおいてやらなければいけない事は次の通りです :
-
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 Step 8 below),
-
サーバー側ドメインオブジェクトを設定します。
(HTTP セッションで変数を設定するなど、、、)
実際に、ステップ 2 で拡張した Cactus テストケースクラスは、
有効なオブジェクトで初期化された幾つかのインスタンス変数を持っています。
(これらはステップ 2 で述べる異なる API オブジェクトです。)
拡張したテストケースクラスに依存して、
これらの変数は、
(
HttpServletRequest型の)
request、
(ServletTestCaseのための
ServletTestCase型、あるいは、
FilterTestCaseのための
FilterConfig型の)
config という変数です。
(下のステップ 8 を参照してください)
-
call the method to test,
-
テスト実行のために、メソッドを呼びだします
-
perform JUnit standard asserts (
asserts(..),
assertEquals(...), fail(...), ...) to
verify that the test was successful
-
テストが成功したか確認するために、
JUnit の標準のアサーション
(
asserts(..),
assertEquals(...), fail(...), ...)
を実行します。
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"));
}
|
public void testXXX()
{
// テスト実行のためのクラスの初期化
SampleServlet servlet = new SampleServlet();
// (例えば)テストしようとしている doSomething() メソッドが
// この変数がセッション中に存在する必要があるので、
// セッション中で、変数を設定します。
session.setAttribute("name", "value");
// (例えば)HttpServletRequest オブジェクトを渡して、
// テスト実行のためにメソッドを呼び出します
String result = servlet.doSomething(request);
// テストが成功したか検証します
assertEquals("something", result);
assertEquals("otherValue", session.getAttribute("otherName"));
}
|
|
| ステップ 6 (オプション) : beginXXX() メソッド/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(), ...).
XXX テストケースの各々について、
それに相当するbeginXXX()メソッドを定義できます。
(オプション)
これは HTTP に関するパラメータを初期化するのに使われます。
(HTTP パラメータ、クッキー、HTTPヘッダ、シミュレーションするURL、など)
これらの値は、testXXX() において、
HttpServletRequest の異なる API
(getQueryString()、getCookies()、
getHeader()、など)
を呼び出すことにより、取り出すことができます。
The signature of the begin method is :
この begin メソッドの記述は次の通りです :
public void beginXXX(WebRequest theRequest)
{
[...]
}
|
where theRequest is the object (provided by Cactus)
that you use to set all the HTTP related parameters.
ここで、
theRequest は、
HTTPに関連する全てのパラメーターを設定するのに使われる
(Cactusにより提供される)オブジェクトです。
The full description of all the HTTP related parameters that you can
set can be found in the javadoc for the WebRequest
class. You should also check the examples provided as part of the
Cactus distribution.
開発者が設定できる全てのHTTP関連のパラメータの完全な記述は、
WebRequest クラスの javadoc にあります。
Cactus ディストリビューションの一部として配布されている例も見てください。
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)
beginXXX() メソッドは、
testXXX() をサーバー側で実行するより前に、
クライアント側で実行されます。
ですから、API オブジェクトをあらわすどのクラス変数へのアクセスもできません。
(それらの値はnullです。)
|
| ステップ 7 (オプション) : endXXX() メソッド/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, ...).
XXX テストケースの各々について、
それに相当するendXXX()メソッドを定義できます。
テストケースより返されたHTTPに関連するパラメータ
(HTTPレスポンスにより返された内容や、
返されたクッキー、返された HTTP ヘッダー、などです)
を検証するために、このメソッドを使えます。
For versions of Cactus up to v1.1, the signature of the end
method is :
1.1 までのバージョンの Cactus では、
end メソッドは次のように記述されます :
public void endXXX(HttpURLConnection theConnection)
{
[...]
}
|
... and some helper methods to extract the response content and
cookies were provided in the AssertUtils class
(see javadoc).
... そして、レスポンスの内容やクッキーを取り出すための、
ユーティリティーメソッドが、
AssertUtils クラスの中で提供されています。
(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.
しかしながら、Cactus 1.2 から、
この記述法は使えなくなりました。
返された内容について洗練されたチェックが必要かどうかにより、
end メソッドについて 2 つの記述法が可能になりました。
複雑なチェックのためには、
HttpUnit
フレームワークと統合をしました。
end メソッドの記述法と完全な説明については、
HttpUnit チュートリアルをご覧ください。
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)
endXXX() メソッドは、
testXXX() がサーバー側で実行された後で、
クライアント側で実行されるので、
API オブジェクトを表す全てのクラス変数へのアクセスはできません。
(それらの値はnullです。)
|
|
| TestCase に個別の事項の詳細/TestCase specific details |
Before reading any of the following detailed tutorials,
make sure you have read the previous general principles.
次の詳しいチュートリアルを読む前に、
前述の一般的な原則について読んだことを確認してください。
|
|
|