3.2.1. 自動テストフレームワーク¶

3.2.1.1.1. JUnit4ベース¶

自動テストフレームワークは、JUnit4をベースとしている。 各種アノテーション、assertメソッドやMatcherクラスなど、JUnit4で提供されている機能を使用する。

3.2.1.1.2. テストデータの外部化¶

テストデータをExcelファイルに記述できる。 データベース準備データや期待するテスト結果などを記載したExcelファイルを 自動テストフレームワークのAPIを通じて使用できる。

3.2.1.1.3. Nablarchに特化したテスト補助機能を提供¶

トランザクション制御やシステム日付設定など、Nablarchアプリケーションに特化したAPIを用意する。

3.2.1.4.1. 命名規約¶

Excelファイル名、ファイルパスには推奨される規約が存在する。この規約に従うことにより、テストクラスで明示的にディレクトリ名やファイル名を指定してファイルを読み込む必要がなくなり、簡潔にテストソースコードを記述できる。また明示的にパスを指定することで任意の場所のExcelファイルを読み込むことも可能である。

3.2.1.4.2. シート内の構造¶

Excelシートの記述方法関する規約について説明を行う。 以下にシートの記述例を記載する。

シート内には、データベースに格納するデータやデータベース検索結果など、さまざまな種類のデータを記載できる。テストデータの種類を判別するために「データタイプ」というメタ情報をテストデータに付与する必要がある。「データタイプ」は、そのテストデータが何を表しているかを示す。

現状、以下のデータタイプが用意されている。

また、データの個数も複数記述できる。

データの種類に依らない共通の書式は以下の通り。

• データ1行目は「データタイプ=値」の形式で、データタイプと値を記載する。
• 2行目以降の書式はデータタイプにより異なる。

　データタイプとは、そのデータが何を表すかを特定するための情報である。 例えばそのデータが、データベースに投入されるべきデータである場合は、データタイプ”SETUP_TABLE”を使用する。

例えば、以下のようにデータタイプを記載した場合、そのデータがCOMPOSERテーブルに準備データとして登録されるべきものであることを示している。

SETUP_TABLE=COMPOSER

3.2.1.4.3. コメント¶

セル内に”//”から開始する文字列を記載した場合、そのセルから右のセルは全て読み込み対象外となる。テストデータ自体には含めたくないが、可読性を向上させるために付加情報を記載したい場合には、コメント機能が使用できる。

以下の例では、2行目でテーブルの論理名を、4行目末尾で期待する結果についてコメントしている。

EXPECTED_TABLE=PLAYER

3.2.1.4.4. マーカーカラム¶

テストデータを記述する際、実際のデータには含めたくないがExcelシート上には記述しておきたい場合がある。前述の「コメント」を使用することにより、実際のデータには含まれない情報を記述できるが、「コメント」には、そのセルから右のセルを読み込み対象外にするという性質があるため、左端（または中央）のセルにはコメントを使用できない。

このような場合は、「マーカーカラム」を使用することで、実際のデータには含まれないが Excelシートの見た目上は存在するデータを記述できる。

テストデータの見出し行において、カラム名が半角角括弧で囲まれている場合、そのカラムは「マーカーカラム」とみなされる。マーカーカラムに該当する列はテスト実行時には読み込まれない。

例えば、以下のようなテストデータがあるとする。

LIST_MAP=EXAMPLE_MARKER_COLUMN

上記のテストデータは、半角角括弧で囲まれているカラム[no]が無視されるため、 テスト実行時には以下のテストデータと等価となる。

LIST_MAP=EXAMPLE_MARKER_COLUMN

id	name
U0001	山田
U0002	田中

ここではLIST_MAPの例を挙げたが、それ以外のデータタイプでも同様に使用できる。

3.2.1.4.5. セルの書式¶

セルの書式には、文字列のみを使用する。 テストデータを作成する前に、全てのセルの書式を文字列に設定しておくこと。

罫線やセルの色付けについては任意に設定可能である。罫線やセルの色付けを行うことでデータが見やすくなり、レビュー品質や保守性の向上が期待できる。

3.2.1.4.6. セルへの特殊な記述方法¶

自動テストの利便性を向上させるために、いくつかの特殊記法を提供する。 下記表が、本フレームワークで提供する特殊な記述方法となっている。

3.2.1.5.1. テストメソッドの実行順序に依存しないテストを作成する¶

テストソースコード、テストデータ作成時には、テストメソッドの実行順序によって、テスト結果が変わらないように留意する。単に順序だけでなく、クラス単体でテストしても、複数まとめてテストしても同じ結果にならなければならない。

特に、本フレームワークではテスト中にコミットが行われるため、前後のテストによってデータベースの内容が変更される可能性が高い。よって、自テストクラスで必要となる事前条件については、全て自テストクラス内で準備するようにしておかなければならない。

これにより、以下のような効果が得られる。

• テストの実行順序によって偶然テストが失敗したり偶然成功する、という事態を防ぐ。
• そのテストのデータまたはソースコードだけで、事前条件が分かる。

マスタデータのような基本的に読み取り専用のテーブルの準備については、共通のExcelファイルを用意してそこに記載すること。テスト実行前に1回だけ実行するか、テスト実行前に事前に準備済みという前提でテストを実行するようにする。

この手法には、以下のようなメリットがある。

• マスタ系のデータを、プロジェクト全体で再利用できる。
• テストデータのメンテナンスが容易になる。
• テスト実行速度が上がる。

3.2.1.5.2. テストデータは全てExcelシートに記述する¶

Excelとテストソースコードとでテストデータが混在していると、可読性、保守性が低下してしまう。テストソースコード中にはテストデータを記載せず、テストデータは全てExcelシートに記載すること。

• Excelシートを見れば、テストケースのバリエーションを把握することができる。
• テストデータはExcelシート、テストロジックはテストソースコードと役割分担が明確になる。
• Excelシートを読み込む構造にしておくことで、容易にテストケースを追加できる。
• テストソースコードの重複を大幅に削減できる(テストソースコード中に単純にリテラル値でデータを記載すると、データのバリエーションが増加すると重複したコードが作られてしまう)。

3.2.1.5.3. 複数のデータタイプ使用時はデータタイプごとにまとめてデータを記述する¶

複数のデータタイプを使用する場合、使用するデータタイプごとにまとめてデータを記述すること。 複数のデータタイプを混在させてデータを記述してしまうと、データの読み込みが途中で終了しテストが正しく実行されない。

例えば、 以下のようにデータタイプを記述した場合、 TABLE2 までのデータしか評価されず、 TABLE3 以降のデータに誤りがあってもテストは成功してしまう。

EXPECTED_TABLE=TABLE1
:
EXPECTED_COMPLETE_TABLE=TABLE2
:
EXPECTED_TABLE=TABLE3
:
EXPECTED_COMPLETE_TABLE=TABLE4
:

全てのデータが正しく評価されるようにするには、 以下のようにデータタイプごとにまとめてデータを記述すること。

EXPECTED_TABLE=TABLE1
:
EXPECTED_TABLE=TABLE3
:
EXPECTED_COMPLETE_TABLE=TABLE2
:
EXPECTED_COMPLETE_TABLE=TABLE4
: