<?xml version="1.0" encoding="Windows-31J"?>

<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">

<document>
  <header>
    <title>Cactus アーキテクチャ</title>
    <authors>
      <person name="Vincent Massol" email="vmassol@apache.org"/>
    </authors>
  </header>

  <body>

    <s1 title="Cactus の仕組み">

      <p>
        UML シーケンス図は<link href="how_it_works_uml.html">ここ</link>
        をクリックしてください。

        Click <link href="how_it_works_uml.html">here</link> for a UML
        sequence diagram.
      </p>

      <figure src="images/archi.jpg" alt="Cactus のアーキテクチャ"/>

      <note>
        Cactus はJUnit <code>Testcase</code> を拡張する
        いくつかの<code>TestCase</code> クラスと、何種類かのリダイレクタ
        (Servlet リダイレクタ、JSP リダイレクタ、...)を提供します。
        上の図は Cactus の仕組みを示す一般的な図です。
        各リダイレクタ・プロキシーについての詳細は次章以降で見ていきます。

        Cactus provides several <code>TestCase</code> classes that extends the
        JUnit <code>Testcase</code> and it also provides several kind of
        redirectors (Servlet Redirector, JSP Redirector, ...). The diagram
        above is a generic diagram which serves to explain the principles.
        You'll find details for a specific redirector proxy in the next
        section.
      </note>
      <note>
        YYYTestCase = ( ServletTestCase | FilterTestCase | JspTestCase )
      </note>
      <note>
        XXX はテスト・ケースの名前です。
        各 YYYTestCase クラスはいくつかのテスト・ケースを含んでいます。

        XXX is the name of the test case. Each YYYTestCase class contains
        several test cases.
      </note>

      <p>
        では、これがどのように動作するのか、
        いくつかのステップを踏みながら見ていきましょう。
        あなたのテスト・ケース・クラス <code>YYYTestCase</code>
        の中の各 <code>testXXX()</code> メソッドに対しては、
        以下の操作が行なわれます。

        Let's go through the different steps to understand how it works. Here
        is what happens for each <code>testXXX()</code> method in your
        test case class (derived from <code>YYYTestCase</code>) :
      </p>
      <ol>
        <li>
          JUnit の Test Runner が <code>YYYTestCase.runTest()</code> 
          を呼び出します。このメソッドは <code>beginXXX(WebRequest)</code>
          を探し出して、それが見つかれば実行します。
          これはクライアント側(つまり、サーバ・エンジンの外)で実行されます。
          <code>beginXXX()</code> に渡される <code>WebRequest</code> 
          パラメータは、ステップ2 のリダイレクタ・プロキシーに送られる
          HTTP ヘッダや HTTP パラメータなどの設定に使用されます。

          The JUnit Test Runner calls a <code>YYYTestCase.runTest()</code>
          method. This method looks for a
          <code>beginXXX(WebRequest)</code> method and executes it if
          one is found. This is executed on the client side (i.e. not in a
          server engine). The <code>WebRequest</code>
          parameter passed to the <code>beginXXX()</code> method is used
          to set the HTTP headers, the HTTP parameters, ... that will be
          sent in step 2 to the Redirector proxy.
        </li>
        <li>
          <code>YYYTestCase.runTest()</code> 
          メソッドはリダイレクタ・プロキシーに対して HTTP 接続を開始します。
          <code>beginXXX()</code> 
          メソッドの中で設定された全てのパラメータは 
          HTTP リクエストの一部(HTTP ヘッダ、HTTP パラメータ、...)
          として送られます。

          The <code>YYYTestCase.runTest()</code> method then opens an HTTP
          connection to the Redirector proxy. All the parameters set up
          in the <code>beginXXX()</code> method are sent in the HTTP request
          (HTTP headers, HTTP parameters, ...)
        </li>
        <li>
          リダイレクタ・プロキシーは、サーバ側で
          あなたのテスト・ケース・クラスのためのプロキシーとして動作します。
          これはつまり、 あなたのテスト・ケース・クラスは
          二回インスタンス化されるということを意味しています: 
          一回はクライアント側で(JUnit の Test Runner によって)、
          もう一回はサーバ側で(リダイレクト・プロキシーによって)です。
          クライアント側のインスタンスは <code>beginXXX()</code> 
          メソッドと <code>endXXX()</code> 
          メソッドを実行するのに使用され(ステップ1 とステップ8 を参照)、
          サーバ側のインスタンスは <code>testXXX()</code> 
          メソッドを実行するのに使用されます(ステップ4 を参照)。
          リダイレクタ・プロキシーの働きは以下の通りです。

          The Redirector proxy acts as a proxy on the server side for your
          test case class. It means that your test case class is instantiated
          twice : once on the client side (by the JUnit Test Runner) and once
          on the server side (by the Redirector proxy). The client side
          instance is used for executing the
          <code>beginXXX()</code> and <code>endXXX()</code> methods (see
          steps 1 and 8) and the server side instance is used for executing
          the <code>testXXX()</code> methods (see step 4). The Redirector
          proxy does the following :
          <ul>
            <li>
              リフレクションを利用して、
              あなたのテスト・クラスをインスタンス化します。
              そして、いくつかの暗黙のオブジェクト(これは
              <code>YYYTestCase</code> のクラス変数です)を設定します。
              どのような暗黙のオブジェクトが設定されるかは、
              リダイレクタ・プロキシーによって異なります(次章を参照)。

              creates an instance of your test class using reflection. It
              then sets specific implicit objects (which are class
              variables of <code>YYYTestCase</code>). These implicit objects
              depend on the redirector proxy (see next section).
            </li>
            <li>
              サーバ・オブジェクトのための
              Cactus ラッパー(<code>HttpServletRequest</code>、
              <code>ServletConfig</code>、<code>ServletContext</code>、...)
              をいくつか生成します。
              これらのラッパーはテスト環境をシミュレートした値を返すように、
              いくつかのメソッドをオーバーライドしています。
              たとえば、Cactus フレームワークは URI をシミュレートする
              (つまり、リダイレクタ・プロキシーの URI ではなく、
              テスト対象の URI が指定されたかのように振舞う)ことができます。
              このために、<code>getServerName()</code>、
              <code>getServerPort()</code>,
              <code>getRequestURI()</code>, ... といったメソッドは
              (もしユーザによって定義されていれば)シミュレートされた
              URI に基く値を返します。

              creates instances of Cactus wrappers for some server objects
              (<code>HttpServletRequest</code>, <code>ServletConfig</code>,
              <code>ServletContext</code>, ...). This is to be able to
              to override some methods in order to return simulated values.
              For example, the Cactus framework can simulate an URI (i.e.
              act as if this URI was called instead of the Redirector proxy
              URI). Thus, the <code>getServerName()</code>,
              <code>getServerPort()</code>,
              <code>getRequestURI()</code>, ... methods return values based
              on the simulated URI (if there is any defined by the user).
            </li>
            <li>
              ユーザの指定に従って、HTTP セッションを生成します(ユーザは
              <code>beginXXX()</code>  メソッドの中で
              <code>WebRequest.setAutomaticSession(boolean)</code>
              を使用することによって、 
              セッションを生成するかどうかを指定できます。
              デフォルトではセッションは常に生成されます)。
              次に、リダイレクタはリフレクションによって暗黙のオブジェクト 
              <code>session</code> に値を代入します。

              creates an HTTP Session if the user has expressed the wish
              (using the
              <code>WebRequest.setAutomaticSession(boolean)</code>
              code in the <code>beginXXX()</code> method. By default a session
              is always created) and the redirector fills by reflection the
              <code>session</code> implicit object.
            </li>
          </ul>
        </li>
        <li>
          テスト・クラス内の <code>setUp()</code>、<code>testXXX()</code>、
          <code>tearDown()</code> メソッドが(この順番で)実行されます。
          これらはリダイレクタ・プロキシーがリフレクションを使用して
          呼び出します。もちろん、<code>setUp()</code> と
          <code>tearDown()</code>は(JUnit と同様)オプションです。

          The <code>setUp()</code>, <code>testXXX()</code>
          and <code>tearDown()</code> methods of your test class are executed
          (in that order). They are called by the Redirector proxy using
          reflection. Of course, <code>setUp()</code> and
          <code>tearDown()</code> are optional (same as in JUnit).
        </li>
        <li>
          <code>testXXX()</code> メソッドは、テストのために
          あなたのサーバ側コードを呼び出し、テストを実行して、
          JUnit のassert API を使用して結果を確認します(<code>assert()</code>、
          <code>assertEquals()</code>、<code>fail()</code>、...)。

          Your <code>testXXX()</code> method calls your server
          side code to test, executing the test and using the JUnit assert API
          to assert the result (<code>assert()</code>,
          <code>assertEquals()</code>, <code>fail()</code>, ...)
        </li>
        <li>
          もしテストが失敗すれば、<code>testXXX()</code> 
          メソッドはリダイレクタ・プロキシーによって捕捉される例外を
          スローします。

          If the test fails, your <code>testXXX()</code> methods
          throws exceptions which are caught by the Redirector proxy.
        </li>
        <li>
          例外が発生すると、リダイレクタ・プロキシーは例外に関する情報
          (名前、クラス、スタック・トレース)をクライアント側に返します。
          その例外に関する情報は JUnit によって Test Runner 
          のコンソールに表示されます。

          If an exception has been raised, the Redirector proxy returns the
          information about the exception (it's name, class, stack trace) back
          to the client side. Information about the exception will then be
          printed by JUnit in it's Test Runner console.
        </li>
        <li>
          もし例外が発生しなければ、<code>YYYTestCase.runTest()</code>
          メソッドは<code>endXXX(org.apache.cactus.WebResponse)</code>
          メソッドか<code>endXXX(com.meterware.httpunit.WebResponse)</code> 
          メソッド(このシグネチャは<link href="howto_httpunit.html">HttpUnit
          との連携</link>に使用されます)を探し出して、
          それが見つかれば実行します。この段階で、あなたは返ってきた
          HTTP ヘッダやクッキー、Servlet の出力などをチェックすること
          ができます。<code>endXXX()</code> メソッドの中で JUnit の
          assert と、Cactus によって提供される
          ヘルパー・ユーティリティ・クラスを使用してください。

          If no exception occurred, the <code>YYYTestCase.runTest()</code>
          method looks for an <code>endXXX(org.apache.cactus.WebResponse)</code>
          or <code>endXXX(com.meterware.httpunit.WebResponse)</code> (this
          signature is used for <link href="howto_httpunit.html">HttpUnit
          integration</link>) method and executes it if found. At this stage,
          you have the opportunity to check returned HTTP headers, Cookies and
          the servlet output stream in the <code>endXXX()</code> method, again
          using JUnit asserts and helper utility classes provided by Cactus.
        </li>
      </ol>

      <s2 title="リダイレクタ・プロキシー">

        <p>
          Cactus はリダイレクタ・プロキシーの実装を 3種類、提供しています
          (これらの使用方法に関する詳細は
          <link href="howto_testcase.html">TestCase Howto</link> 
          チュートリアルを参照してください)。

          Cactus provides 3 implementations of Redirector Proxies
          (see the <link href="howto_testcase.html">TestCase Howto</link>
          tutorial for more details on how to use these redirectors) :
        </p>
        <ul>
          <li>
            <em>Servlet リダイレクタ</em>。このリダイレクタは Servlet
            として実装されており、servlet のメソッドや Servlet 
            オブジェクト(<code>HttpServletRequest</code>、...)
            を使用する java クラスの単体テストに使用されます。

            <em>A Servlet Redirector</em>. This redirector is a servlet that
            should be used for unit testing servlet methods or any java class
            that uses servlet objects (<code>HttpServletRequest</code>, ...)
          </li>
          <li>
            <em>JSP リダイレクタ</em>。このリダイレクタは JSP 
            ページとして実装されており、
            JSP の暗黙のオブジェクト(<code>PageContext</code>、...)
            にアクセスする必要のあるサーバ・コードの単体テストに使用されます。
            JSP リダイレクタはカスタム・タグ・ライブラリのテストにも使用されます。
            <em>A JSP Redirector</em>. This redirector is a JSP page that
            should be used for unit testing server code that need access to
            JSP implicit objects (<code>PageContext</code>, ...). The JSP
            Redirector should be used to unit test custom Tag libraries.
          </li>
          <li>
            <em>Filter Redirector</em>。このリダイレクタは Servlet
            Filter として実装されており、Servlet Filter や Filter オブ
            ジェクト(<code>FilterConfig</code>、...)を使用する java 
            クラスの単体テストに使用されます。

            <em>A Filter Redirector</em>. This redirector is a Servlet Filter
            that should be uses for unit testing Servlet Filters or any java
            class that uses filter objects (<code>FilterConfig</code>, ...).
          </li>
        </ul>

        <s3 title="Servlet リダイレクタ・プロキシー">

          <figure src="images/archi_servlet.jpg"
            alt="Servlet リダイレクタのアーキテクチャ"/>

          <p>
            クライアント側は Servlet リダイレクタに対して二回、
            HTTP 接続します。一回目はテストを実行し、
            Servlet の出力を受け取るためのもので、
            二回目はテスト結果を受け取るためのものです。
            これによってテストが失敗したときの例外の情報(メッセージや
            スタック・トレースなど)を取得することができます。
            テスト結果は一旦<code>ServletContext</code>内の変数に保存され、
            二回目の HTTP 接続によって取得されます。

            The client side opens 2 HTTP connections to the Servlet redirector.
            Once to execute the tests and retrieve the servlet output stream and
            a second time to get the test result. This is to be able to get
            the exception data (message, stack trace, ...) if the test failed.
            The test results are stored in a variable which is put in the
            <code>ServletContext</code> and then retrieved on the second HTTP
            connection.
          </p>

        </s3>

        <s3 title="JSP リダイレクタ・プロキシー">

          <figure src="images/archi_jsp.jpg" alt="JSP リダイレクタのアーキテクチャ"/>

          <p>
            クライアント側は JSP リダイレクタに対して二回、
            HTTP 接続します。一回目はテストを実行し、
            Servlet の出力を受け取るためのもので、
            二回目はテスト結果を受け取るためのものです。          
            これによってテストが失敗したときの例外の情報(メッセージや
            スタック・トレースなど)を取得することができます。
            テスト結果は一旦<code>ServletContext</code>内の変数に保存され、
            二回目の HTTP 接続によって取得されます。

            The client side opens 2 HTTP connections to the JSP redirector.
            Once to execute the tests and retrieve the servlet output stream and
            a second time to get the test result. This is to be able to get
            the exception data (message, stack trace, ...) if the test failed.
            The test results are stored in a variable which is put in the
            <code>ServletContext</code> and then retrieved on the second HTTP
            connection.
          </p>

        </s3>

        <s3 title="Filter リダイレクタ・プロキシー">

          <figure src="images/archi_filter.jpg" alt="フィルター・リダイレクタのアーキテクチャ"/>

          <p>
            クライアント側は Filter リダイレクタに対して二回、
            HTTP 接続します。一回目はテストを実行し、
            Servlet の出力を受け取るためのもので、
            二回目はテスト結果を受け取るためのものです。          
            これによってテストが失敗したときの例外の情報(メッセージや
            スタック・トレースなど)を取得することができます。
            テスト結果は一旦<code>ServletContext</code>内の変数に保存され、
            二回目の HTTP 接続によって取得されます。


            The client side opens 2 HTTP connections to the Filter redirector.
            Once to execute the tests and retrieve the servlet output stream and
            a second time to get the test result. This is to be able to get
            the exception data (message, stack trace, ...) if the test failed.
            The test results are stored in a variable which is put in the
            <code>ServletContext</code> and then retrieved on the second HTTP
            connection.
          </p>

        </s3>

      </s2>

    </s1>

  </body>
</document>
