See ServletTestCase request implicit object for documentation.

ServletTestCase の request 暗黙オブジェクトのドキュメントをご覧ください。

See ServletTestCase response implicit object for documentation.

ServletTestCase の response 暗黙オブジェクトのドキュメントをご覧ください。

ServletTestCase の config 暗黙オブジェクトのドキュメントをご覧ください。

ServletTestCase の session 暗黙オブジェクトのドキュメントをご覧ください。

Cactus does not wrap the out object.

Cactus は out オブジェクトをラップしません。

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 for details.

このオブジェクトはタグのボディをシミュレートしている場所に、 レスポンスに対してデータを書き加えるのに使えます (タグがそのボディを書き換えない場合)。 もし、タグがそのボディを書き換える場合、 シミュレートされたボディを書き出す前に、BodyContent オブジェクトを生成する必要があります。 詳しくは bodyContent を見てください。

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 ディストリビューションで提供されるサンプルもご覧ください。

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 Body Tags for more information.

JspTestCase は実際には、 BodyTags での使用のために bodyContent 暗黙オブジェクトを提供していません。 しかしながら、それを得ることは、ここで述べる価値があるほど簡単です。 pageContext.pushBody() を呼び出すと、 JspWriter を継承した javax.servlet.jsp.tagext.BodyContent 型のオブジェクトを返します。 この呼び出しは、ページスコープに保存されている変数 (従ってpageContext.getOut()の値を)"out" の値を変更します 。 bodyContent オブジェクトにテストコンテンツを置くためには、 単に、そのライターメソッドを使えばよいのです。 問題部分の Sun の API リファレンスを引用すると次の通りです: "BodyContent のコンテンツは評価の結果なので、 アクションやそれに類するもの含まず、 その実行の結果を含むということに注意してください。" 詳しくは ボディタグ をご覧ください。

It's important to balance calls to 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() 内で呼び出すことです。

Instantiate a copy of the tag you wish to test.

テストしたいタグのコピーを初期化します

SomeTag tag = new SomeTag();

Call the setPageContext() method with the implicit object provided by Cactus to register the pageContext with the tag.

タグに pageContext を登録するために、 Cactus により提供される暗黙オブジェクトにより、 setPageContext() メソッドを呼び出します。

tag.setPageContext(pageContext);

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 のコード部分は :

<someTag foo="10" bar="11"/>

You would need to use the following:

次を使う必要があります :

someTag.setFoo("10");
someTag.setBar("11");

If you would like the tag you are testing to access a parent tag, you will need to call

テストしたいタグが親のタグへアクセスしたい場合には、 次のように呼び出す必要があります。

tag.setParent(enclosingTag);

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() の呼び出しが含まれている事を確認しなければなりません。 詳しくは、 Body Tags の節を見てください。

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 オブジェクトを通じて間接的にアクセスすることにより これらのスコープにオブジェクトを置くことができます。

request.setAttribute("key", new DomainObject("testValue"));
//or
pageContext.setAttribute("key", new DomainObject("testValue"), PageContext.REQUEST_SCOPE);

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 の出力レスポンス中のタグのボディを含むよう知らせます。 ですから、条件によりその属性の一つの値に基づきボディを挿入するタグは、次のように検証されます :

tag.setValueThatResultsInInclude("correct value");
assertEquals(Tag.EVAL_BODY_INCLUDE, tag.doStartTag());

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" キーのリクエストで、 オブジェクトの集まりを変換したか検証するためのものです。

catalogListTag.doStartTag();
Collection catalogs = (Collection)request.getAttribute("catalogs");
assertNotNull(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

This example uses the endXXX() signature from Cactus 1.2 or above.

この例では Cactus 1.2 以上の endXXX()の書式を用いています。

public void endSomeTagTest (WebResponse response)
{
    String output = response.getText();
    assertEquals("<b>expected output</b>", output);
}

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 ループを作ります :

//[...tag set up and early life cycle methods omitted...]

int count = 0;
do
{
    count++;

} while (tag.doAfterBody() == tag.EVAL_BODY_AGAIN);

tag.doEndTag();

//based on setUp we expect 9 repetitions
assertEquals(9, count);

//[...タグの設定と初期のライフサイクルメソッドは省略します...]

int count = 0;
do
{
    count++;

} while (tag.doAfterBody() == tag.EVAL_BODY_AGAIN);

tag.doEndTag();

// 設定に基づき、9 回の繰り返しを想定します
assertEquals(9, count);

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:

ボディタグをテストするには、テストが、幾分複雑なライフサイクルを繰り返す必要があります :

//standard set up
//標準セットアップ
YourTag tag = new YourTag();
tag.setPageContext(this.pageContext);
tag.doStartTag();

//obtain the bodyContent object--presumably doStartTag has returned 
//EVAL_BODY_TAG or EVAL_BODY_BUFFERED.
//bodyContent オブジェクトを得る -- 恐らく doStartTag は
//EVAL_BODY_TAG と EVAL_BODY_BUFFERED のいずれかを返したと思われます
BodyContent bodyContent = this.pageContext.pushBody();
this.tag.setBodyContent(bodyContent);
this.tag.doInitBody();


//write some "output" into the bodyContent so that endXXX can test for it.
//endXX が testできるよう、bodyContentに何か出力します
bodyContent.println("Some content");
bodyContent.print("Some evaluated content " + (5 + 9));

//actually handles the processing of the body
//実際にボディの処理を扱います
tag.doAfterBody();

//after the body processing completes
//ボディの処理が完了した後で
tag.doEndTag();

//finally call popBody
//最後にpopBodyを呼びます
this.pageContext.popBody();

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 オブジェクトのみしか受け取りません。) しかしながら、テスト環境においては、 テスト作業を簡単にするように仮定を設けます

Again, you can check that the body of the tag was handled correctly by verifying the total output in the 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 クラスのテストをサポートする固有のサービスを提供していません。

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 の例は次の通りです :

<%@page import="junit.framework.Assert"%>
<%@taglib uri="WEB-INF/yourTagLib.tld" prefix="example"%>

Here is the custom tag this page verifies:
ここに、このページで検証するカスタムタグがあります:
<example:someTag variableName="foo" variableValue="bar"/>

Here is the JUnit assert that checks whether the tag correctly created a 
scripting variable named <code>foo</code> with the value "bar":
タグが、値を"bar"を持つ名前<code>foo</code>のスクリプト変数が正しく生成したかどうか
チェックする 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() は、 これをうまく処理します :

public void testSomeTag () throws Exception
{
    pageContext.include("/test_some_tag.jsp");

    //an assert to check whether the page also mapped foo into the session
    //ページが、そのセッション中でも foo をマップしたかチェックするアサーション
    assert("bar", session.getAttribute("foo"));
}

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 により失敗 (開発者の望んでいるのは、まさにこれです) としてログに書き込まれます。

Any output that the test JSP generates can be checked normally in the endXXX method.

通常、 テスト JSP 生成するどのような出力でも、 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 を配備しなければなりません。