Your test case class should extend JspTestCase
whenever you are unit testing :
次のようなものを単体テストするときには、
いつでもテストケースクラスは
JspTestCase を拡張しなければなりません :
PageContext, ...)
PageContextなど)JSP API オブジェクトを使った、どんな
java コードでも
This tutorial focuses on testing custom tags, as they are the principal code which uses the JSP API objects. Future versions of this tutorial will expand upon testing actual JSPs.
本チュートリアルでは、 JSP API オブジェクトを使った原則的コードであるので、 カスタムタグのテストに焦点を当てています。 将来、このチュートリアルは実際の JSP のテストについても書き加えられるでしょう。
Custom tags consist of entries in a Tag Library Descriptor file (TLD) and a tag handler class. Cactus provides the facility to test both aspects of a custom tag. However, since the TLD contains no logic, you will use Cactus primarily to test the tag handler class.
カスタムタグは、 タグライブラリ記述ファイル(TLD)に登録された項目および、 タグハンドラークラスにより構成されています。 Cactus では、その両方のカスタムタグのテストの機能を提供しています。 しかしながら、TDL にはロジック含まれていないので、 Cactus をタグハンドラークラスのテストをするために、主に使うでしょう。
To test the tag handler class, use the implicit objects provided by
JspTestCase to set up the initial state for the test. Then create
and initialize your custom tag using the pageContext
implicit
object. After setting up the tag, call the lifecycle methods
implemented by your tag in the correct order and verify that the
methods return the expected results. The tag's output can be
inspected in the endXXX() method.
タグハンドラークラスをテストするには、
JstTestCase により提供される、
テストの初期状態を設定する暗黙オブジェクトを使います。
そして次に、pageContext 暗黙オブジェクトを使って、
自分のカスタムタグを生成、初期化します。
そのタグを設定した後に、
正しい順序で、
自分のタグで実装された lifecycle メソッドを呼び出し、
そのメソッドが期待した結果を返すか検証します。
タグの出力は、endXXX() メソッドで調べることができます。
For an additional degree of integration testing, you can create a
JSP that exercises your custom tag and call it from within a regular
Cactus test case. See the section on
結合テストの追加の程度によって、
自分のカスタムタグをテストするJSP を作り、
それを通常の Cactus テストケースから呼び出す事ができます。
詳しくは、
Cactus automatically initializes the following implicit objects.
They are made available to your setUp(),
testXXX() and tearDown() methods as
instance variables of the JspTestCase class (and thus
as instance variables of your test case class).
Cactus は自動的に次に示す暗黙オブジェクトを初期化します。
JspTestCase クラスのインスタンス変数として、
(従って、自分のテストケースクラスのインスタンス変数として)
自分のsetUp()、testXXX()、および
tearDown() メソッドで利用可能になります。
The provided implicit objects are :
提供される暗黙オブジェクトは次の通りです :
See ServletTestCase
request
implicit object for documentation.
ServletTestCase の
request
暗黙オブジェクトのドキュメントをご覧ください。
See ServletTestCase
response
implicit object for documentation.
ServletTestCase の
response
暗黙オブジェクトのドキュメントをご覧ください。
ServletTestCase の
config
暗黙オブジェクトのドキュメントをご覧ください。
ServletTestCase の
session
暗黙オブジェクトのドキュメントをご覧ください。
| Instance variable name |
out
|
| Class name |
public javax.servlet.jsp.JspWriter
|
| インスタンス変数名 |
out
|
| クラス名 |
public javax.servlet.jsp.JspWriter
|
You can use this object to write data to the response, thereby
simulating the body of a tag (if the tag does not modify its body). If
the tag does modify its body, then you will need to
generate a BodyContent object before writing out the simualted body.
See bodyContent
このオブジェクトはタグのボディをシミュレートしている場所に、
レスポンスに対してデータを書き加えるのに使えます
(タグがそのボディを書き換えない場合)。
もし、タグがそのボディを書き換える場合、
シミュレートされたボディを書き出す前に、BodyContent
オブジェクトを生成する必要があります。
詳しくは
bodyContent
| Instance variable name |
pageContext
|
| Class name |
org.apache.cactus.server.PageContextWrapper
, which inherits from
javax.servlet.jsp.PageContext
|
| インスタンス変数名 |
pageContext
|
| クラス名 |
javax.servlet.jsp.PageContext を継承した
org.apache.cactus.server.PageContextWrapper
|
Custom tags rely exclusively on the pageContext object to
provide information about the enclosing JSP. Therefore this is the
most important implicit object for testing custom tags. Cactus
provides a very thin wrapper that ensures that all of the objects that
pageContext returns (such as the ServletRequest
from pageContext.getRequest()) are the correctly
wrapped versions available in the other implicit variables.
カスタムタグは排他的に、
入れ物である JSP についての情報を提供するための
pageContext オブジェクトに依存しています。
従って、これは、カスタムタグをテストするのに最も重要な暗黙オブジェクトです。
Cactus は、
pageContext が返す
(pageContext.getRequest() から返される
ServletRequest のように)
オブジェクトの全てが、
他の暗黙変数で利用可能な正しくラップされたバージョンであることを保証するとても薄いラッパーを提供します。
See the javadoc for
org.apache.cactus.server.PageContextWrapper
for more details. You should also look at the
samples provided in the Cactus distribution.
詳しくは、
org.apache.cactus.server.PageContextWrapper
の javadoc をご覧ください。
Cactus ディストリビューションで提供されるサンプルもご覧ください。
| Instance variable name |
bodyContent
|
| Class name |
javax.servlet.jsp.tagext.BodyContent
|
| インスタンス変数名 |
bodyContent
|
| クラス名 |
javax.servlet.jsp.tagext.BodyContent
|
JspTestCase does not actually provide a bodyContent
implicit object for use with BodyTags. However, obtaining
one is so easy that it deserves mention here. Calling
pageContext.pushBody() returns an object of type
javax.servlet.jsp.tagext.BodyContent (which inherits from
JspWriter). This call also changes the value of the
"out" variable stored in page scope (and thus the value of
pageContext.getOut()). To put test content into the
bodyContent object, simply use its writer methods. To
quote Sun's API reference on the matter: "Note that the content of
BodyContent is the result of evaluation, so it will not contain
actions and the like, but the result of their invocation."
See
JspTestCase は実際には、
BodyTags での使用のために
bodyContent 暗黙オブジェクトを提供していません。
しかしながら、それを得ることは、ここで述べる価値があるほど簡単です。
pageContext.pushBody() を呼び出すと、
JspWriter を継承した
javax.servlet.jsp.tagext.BodyContent
型のオブジェクトを返します。
この呼び出しは、ページスコープに保存されている変数
(従ってpageContext.getOut()の値を)"out" の値を変更します
。
bodyContent オブジェクトにテストコンテンツを置くためには、
単に、そのライターメソッドを使えばよいのです。
問題部分の Sun の API リファレンスを引用すると次の通りです:
"BodyContent のコンテンツは評価の結果なので、
アクションやそれに類するもの含まず、
その実行の結果を含むということに注意してください。"
詳しくは
pushBody() with calls to
popBody()--otherwise many servlet engines will not
output the tag's body. The easiest way to accomplish this is to
call pushBody in setUp() and popBody()
in tearDown().
pushBody() の呼び出しと、
popBody() の呼び出しの回数が合っていることが重要です。
さもないと、多くのサーブレットエンジンでは、
タグの内容を出力しないでしょう。
これを行う最も簡単な方法は、
pushBody を setUp() 内で呼び出し、
popBody() を setUp() 内で呼び出すことです。
Creating the test fixture for a custom tag test involves several
steps. The exact order of the steps can vary depending on the
needs of the test. For instance, placing the test data in the
correct scope would probably happen before a real JSP began its
execution. You can emulate this, or choose to do it after the
tag has been in initialized (as described below). In most cases
you can determine the exact order of the steps based on what
is most convenient for a given test (some steps may be specific
to only one test in the TestCase and so should
be executed after common setUp() code).
カスタムタグテストのためのテストの環境を作るには、
幾つかの手順があります。
手順の正しい順序は、必要するテストによって変わります。
例えば、正しい場所にテストデータを置くことは、
実際の JSP が実行される前に、行っておかなくてはなりません。
開発者は、これをエミュレーションしたり、
(下で述べるように)タグが初期化された後で、
行うか選べます。
ほとんどのケースでは、
与えられたテストに対して何が最も便利であるかに基づき、
手順の正確な順番を決定できます。
(幾つかの手順は
TestCase 中の、
たった一つのテストに特定のものかもしれないので、
共通の setUp() コードの後で実行すべきかもしれない。)
Instantiate a copy of the tag you wish to test.
テストしたいタグのコピーを初期化します
Call the setPageContext() method with the implicit
object provided by Cactus to register the pageContext with the
tag.
タグに pageContext を登録するために、
Cactus により提供される暗黙オブジェクトにより、
setPageContext() メソッドを呼び出します。
If your tag takes attributes, call setter methods to initialize the tag's state. Setters on the tag handler class represent the attributes of custom tags. Thus to emulate this JSP fragment:
自分のタグが属性を取る場合、 タグの状態を初期化するために設定用メソッドを呼び出します。 タグハンドラークラスの設定用メソッドは、 カスタムタグの属性をあらわします。 ですから、これをエミュレートするには、 次をエミュレートするには、JSP のコード部分は :
You would need to use the following:
次を使う必要があります :
If you would like the tag you are testing to access a parent tag, you will need to call
テストしたいタグが親のタグへアクセスしたい場合には、 次のように呼び出す必要があります。
This will allow tag to successfully call getParent
and TagSupport.findAncestorWithClass(). Of course
enclosingTag will have to be instantiated and
set up as well, including another call to
setParent() if you would like to simulate multiple
levels of nesting.
これにより、タグが
getParent および
TagSupport.findAncestorWithClass()
を首尾よく呼び出せるようになります。
もちろん、
多段の入れ子をシミュレートしたい場合、
setParent() の別の呼び出しを含めて、
enclosingTag が同様に初期化され、
設定されなければなりません。
自分のタグがそのボディを処理する場合、
BodyContent を得るために
pageContext.pushBody() を
呼び出します。
この手順を行う場合、
タグの実行が終了した後で、
pageContext.popBody() の呼び出しが含まれている事を確認しなければなりません。
詳しくは、
Set up any necessary page state by putting test objects into the
appropriate scopes. Tags frequently access data in the
session, the request, or the page. If your tag operates on data
contained in any of these (or in the application scope), be sure
to set up this part of the test fixture. Objects can be placed
in these scopes by using the implicit objects provided by Cactus
directly, or by accessing them indirectly through the
pageContext object.
テストオブジェクトを、適切なスコープに置くことにより、
必要なページ状態のセットアップを行います。
タグは頻繁にセッション、リクエスト、あるいはページ
(あるいは、アプリケーションスコープ)
の中のデータにアクセスします。
自分のタグが、これらのいずれかに含まれるデータを処理する場合、
テスト環境のこの部分を必ずセットアップしてください。
Cactus により直接提供される暗黙オブジェクトを用いて、
あるいは、pageContext
オブジェクトを通じて間接的にアクセスすることにより
これらのスコープにオブジェクトを置くことができます。
Once the tag has been set up and any necessary page data has been placed in the appropriate scopes, testing a custom tag consists of calling the relevant life-cycle methods and then using JUnit asserts to verify the outcome.
タグがセットアップされ、必要なページデータが適切なスコープに置かれたら、 カスタムタグのテストは、関連するライフサイクルメソッドの呼び出しにより構成され、 次に、出力を検証するために、JUnit の使用を宣言します。
Most of the life cycle methods return ints,
which signal that
the container should take a certain action after the method.
For instance, the constant EVAL_BODY_INCLUDE
returned from doStartTag() tells the container to
include the tag's body in the JSP's output response. So a tag
which conditionally includes its body based on the value of one
of its attributes might be verified like this:
ほとんどのライフサイクルメソッドは、
コンテナがそのメソッドの実行後に必ずアクションを受け取るシグナルであるint を返します。
例えば、doStartTag() より返される定数
EVAL_BODY_INCLUDE は、
コンテナに
JSP の出力レスポンス中のタグのボディを含むよう知らせます。
ですから、条件によりその属性の一つの値に基づきボディを挿入するタグは、次のように検証されます :
In addition to "listening" for the signals that your tag sends to
the container, you may want to verify that the tag's execution
has the appropriate effects upon the page data. Use
JspTestCase's implicit objects to verify that the
tag has correctly modified the information. The following
snippet verifies that the CatalogListTag has placed a
collection of objects in the request under the key "catalogs":
自分のタグがコンテナへ送るシグナルの"受信待ち"に加えて、
タグの実行がページデータに対して適切な効果を与えたか検証したいでしょう。
タグが正しく情報を変換したか検証するには、
JspTestCase の暗黙オブジェクトを使います。
次のプログラム部分は
CatalogListTag が
"catalogs" キーのリクエストで、
オブジェクトの集まりを変換したか検証するためのものです。
Use the endXXX method to verify that your tag's
methods have resulted in the correct data being written
to the response.
自分のタグメソッドがレスポンスに対して正しいデータを出力したか検証するためには、endXXX メソッドを使います。
endXXX
endXXX()
signature from Cactus 1.2 or above.
endXXX()の書式を用いています。
There are a few scenarios in custom tag testing that deserve extra attention.
より注意しておくべき、 カスタムタグのテストのシナリオが 2, 3 あります。
To test a tag that repeats its body processing a number of
times, simply create a do-while loop that mimics
the life cycle of an iteration tag:
ボディを何回か繰り返し処理するタグをテストするには、
単に、イテレーションタグのライフサイクルを真似する
do-while ループを作ります :
You can use a count variable (such as the one illustrated in the example) to check whether the tag's body was processed the expected number of times.
(例で示したように) タグのボディが期待した回数処理されたかどうかチェックするのに、 カウンタ変数が利用可能です。
Unless specified otherwise by the deployment descriptor, all
tags can include a body, which can in turn include other tags
or scriptlet expressions. These are automatically evaluated at
run time, and the content of the body is simply written out
if the tag signals it should be (with
EVAL_BODY_INCLUDE for instance). Nothing special
is required to test this sort of tag, since the tag is
unconcerned about its contents.
別の方法で配備記述により指定されない限りは、
全てのタグは、
代りに他のタグやスクリプトレットの式を含んだりできるボディを持つことができます。
これらは実行時に自動的に評価され、
タグのシグナル要求
(例えばEVAL_BODY_INCLUDE )
があれば、単にボディのコンテンツが出力されます。
タグは、そのコンテンツについては関与しないので、
この種類のタグをテストするのに、
特別なものは何も必要ありません。
Testing BodyTags--tags which actually perform some processing
on their content--is a little trickier.
BodyTags can choose to return a constant (
EVAL_BODY_TAG in JSP 1.1,
EVAL_BODY_BUFFERED in 1.2) from
doStartTag() which signals to the container that
the tag would like a chance to handle its own body.
If it receives this result, the container calls
pageContext.pushBody() to obtain a
BodyContentobject. The BodyContent
object is passed to the tag through the tag's
setBodyContent()method. The container then uses
this object (the old out object is saved) to capture all of the
response writing that goes on in the body of the tag. After the
tag's body has been evaluated, the tag itself has a chance to
do something with the result of the evaluation in it's
doAfterBody() method. After the tag has completed
its execution, the container restores the old out object with
a call to pageContext.popBody().
実際に自分の中身を処理を行うタグである BodyTag のテストは、
少しトリッキーです。
BodyTag は、
コンテナへのタグが自分のボディを処理できる機会となるシグナルとなる、
doStartTag() からの戻り値となる定数
(JSP 1.1 ではEVAL_BODY_TAG、
1.2 では EVAL_BODY_BUFFERED)
を選択できます。
この戻り値を受け取ったとき、
BodyContent オブジェクトを得るために、
コンテナはpageContext.pushBody()を呼び出します。
タグのsetBodyContent()メソッドを通じて、
BodyContent オブジェクトがタグに渡されます。
そして、
タグ中で行われていることを出力する全てのレスポンスを捕らえるために、
コンテナはこのオブジェクト(古い out オブジェクトが保存されている)
を使います。
タグのボディが評価された後で、
タグの doAfterBody() メソッドの中で、
タグ自身は評価の結果に対し何かを行うチャンスがあります。
評価が完了した後で、
コンテナは、pageContext.popBody() を呼び出して、
古い out オブジェクトを取り出します。
To test body tags, your test must replicate this somewhat complicated lifecycle. The following code covers all of the steps as they might appear in a typical test:
ボディタグをテストするには、テストが、幾分複雑なライフサイクルを繰り返す必要があります :
This sample does not fully replicate the container's handling of
the tag (for instance, the tag would only receive the
bodyContent object if the result of
doStartTag indicated that it should do so).
However, in a test environment, you can make assumptions if
doing so simplifies the workings of the test.
この例題は、コンテナがタグを扱うことを完全に反映するものではありません。
(例えば、
doStartTag の結果が、そのように指定した場合、
タグは bodyContent オブジェクトのみしか受け取りません。)
しかしながら、テスト環境においては、
テスト作業を簡単にするように仮定を設けます
endXXX() method.
endXXX() メソッドの出力全体を検証することにより、
タグのボディが正しく処理されたことをチェックできます。
Cactus does not offer any specific services to support the
testing of TagExtraInfo classes because they do
not depend on any of the implicit objects.
暗黙オブジェクトのいずれにも依存しないので、
Cactus は
TagExtraInfo クラスのテストをサポートする固有のサービスを提供していません。
You can use Cactus to test how your tag will react when put into a real JSP. This allows you to verify that there are no problems with the deployment descriptor, or unexpected behavior on the part of the container. You accomplish this by writing a small JSP that makes use of your custom tag, and then calling it from within a Cactus test case. You can even use JUnit assertions within scriptlets to verify certain aspects of the Tag's behavior. However, this method requires that you write a separate JSP for each test case (or lump several cases into a single JSP). Both options pose problems, so it may be best to include one or two tests of this type and rely on the more traditional methods described earlier to ensure total coverage.
実際の JSP に挿入したときに自分のタグどう反応するのかテストするために、 Cactus を使うことができます。 これにより、配備記述ファイルに問題が無いか、 コンテナの一部に期待していない振舞いが起きないかなど検証することができます。 これは、自分のカスタムタグを使った小さい JSP を書き、 Cactus テストケースから呼び出すことにより、達成されます。 タグの振舞いのある側面を検証するのにスクリプト中で、JUnit のアサートを使うこともできます。 しかしながら、この方法を使うには、 個々のテストケースに対して、別々の JSP を書かなければなりません。 (あるいは、幾つかのケースを一まとめに一つの JSP に入れなければなりません。) どちらの方法も問題があるので、 方法の 1 あるいは 2 のどちらテストを入れるのが最善の方法かわからず、 全体を保障するには、前に述べたより伝統的な方法に頼ったほうがいいのかもしれません。
All the JSP needs to do is include the tag library that
describes the tag you are testing and makes use of it in
some way. You can import junit.framework.Assert
to do some simple checks on the effects of the tag.
Here is a short example of a JSP that exercises a tag:
全ての JSP でやらなければならないことは、
どうにかして、テストおよび使おうとしているタグを記述したタグライブラリを含めることです。
タグの影響の簡単なチェックを行うために、
junit.framework.Assert をインポートすることもできます。
タグを試す短い JSP の例は次の通りです :
foo with the value "bar":
タグが、値を"bar"を持つ名前fooのスクリプト変数が正しく生成したかどうか
チェックする JUnit のアサーションは次のとおりです:
<%
//attempt to reference foo will cause a translation error if the tag did not
//create the scripting variable
//タグがスクリプト変数を生成しなかったら、
//fooへの参照は変換エラーを発生させるでしょう
Assert.assertEquals("bar", foo);
%>
]]>
It's a bad idea to put too many assertions into the
JSP. In the example above, the creation of a scripting variable
can only be tested within the JSP page. (The
same goes for any objects in page scope, because each JSP
creates its own.) If you
want to use other assertions with this type of test,
call them in your test case after
pageContext.include() (See below for an example.)
JSP にアサーションを入れすぎるのは、あまり賢明とは言えません。
上述の例では、スクリプト変数の生成は、
JSP ページでのみテストできるのです。
(ページスコープの任意のオブジェクトについても同じ事が言えます。
なぜなら、個々の JSP は自分自身を生成するからです。)
この種のテストにおいて他のアサーションを使いたい場合には、
pageContext.include() の後で、
自分のテストケースの中で、それらを呼び出してください。
(下の例をご覧ください。)
テスト JSP を使うには、
JspTestCase の中で、インクルードします。
ユーティリティー関数 pageContext.include() は、
これをうまく処理します :
Exceptions that result from either page translation (such as required attributes being omitted, or the tag missing a part of its descriptor entry) or page execution (such as the tag being unable to find required data in the appropriate scope) are automatically be thrown up to this level. If you do not catch them there they will be logged by Cactus/JUnit as failures--which is just what you want.
(必要な属性が省略されたり、タグの記述子エントリの一部がなかったり、など) ページ変換からの結果、あるいは、 (タグが、適切なスコープ中に、必要なデータを見つけられなかった、など) ページ実行の結果である例外は、 自動的にこのレベルまでスローされます。 そこで、キャッチしない場合、 Cactus/JUnit により失敗 (開発者の望んでいるのは、まさにこれです) としてログに書き込まれます。
endXXX method.
endXXX メソッドにおいて、チェックできます。
Of course, using this strategy means that you need to put
the test_some_tag.jsp in the specified location
within your web application. If you are using JSP test case
your build script should already deploy the redirector JSP, so
it should be easy to include another JSP in the build process.
もちろん、この戦略を使う事は、
test_some_tag.jsp を自分のウェブアプリケーションの指定された場所に置く必要があることを意味します。
JSP テストケースを使っている場合、
ビルド手続きにおいて他の JSP に簡単にインクルードできるように、
自分のビルドファイルは、
転送用 JSP を配備しなければなりません。