3.1.10. リクエスト単体テストの実施方法(バッチ)¶
3.1.10.1. テストクラスの書き方¶
テストクラスは以下の条件を満たすように作成する。
- テストクラスのパッケージは、テスト対象のActionクラスと同じとする。
- <Actionクラス名>RequestTestというクラス名でテストクラスを作成する。
nablarch.test.core.batch.BatchRequestTestSupportを継承する。
例えば、テスト対象のActionクラスが、nablarch.sample.ss21AA.RM21AA001Actionだとすると、テストクラスは以下のようになる。
package nablarch.sample.ss21AA;
// ～中略～
public class RM21AA001ActionRequestTest extends BatchRequestTestSupport {
3.1.10.2. テストメソッド分割¶
１テストケースにつき１テストメソッドを原則とする。 以下の手順により、作成するテストメソッドを決定する。
- 原則として、１つのテストケースに対して１つのテストメソッドを作成する。
- 例外として、複数ケースをまとめて記述した方が効率が良い場合は、複数テストケースを１テストメソッドで行うことを検討する。
バッチ処理では複数のレコードを１度に扱うので、テストデータが比較的多くなる。１テストメソッドに複数のテストケースを記述すると、１つのシートに大量のテストデータを記載することになり、可読性、保守性が低下してしまう。このため原則１テストケース１テストメソッドとしている。
しかし、複数テストケースをまとめて記載したほうが効率が良い場合がある。この場合複数ケースをまとめて記述することを検討する。
- テストケース間の関連が強く、シートを分割することにより可読性が劣化する場合。（例：入力ファイルのフォーマットチェックのテストケース）
- テストデータが少量であるため、１シートに記述しても可読性、保守性に影響しない。
3.1.10.3. テストデータの書き方¶
テストデータを記載したExcelファイルは、クラス単体テストと同様にテストソースコードと同じディレクトリに同じ名前で格納する（拡張子のみ異なる）。
テストデータの記述方法詳細については、「Excelによるテストデータ記述」を参照。
3.1.10.3.1. テストクラスで共通のデータベース初期値¶
ウェブアプリケーションの場合と同様である。「テストクラスで共通のデータベース初期値」を参照。
3.1.10.3.2. テストケース一覧¶
LIST_MAPのデータタイプで１テストメソッド分のケース表を記載する。IDは、testShotsとする。
１ケース毎に以下の要素を持たせる。
| カラム名 | 説明 | 必須 |
|---|---|---|
| no | テストケース番号を1からの連番で記載する。 | 必須 |
| description | そのテストケースの説明を記載する。 | 必須 |
| expectedStatusCode | 期待するステータスコード | 必須 |
| setUpTable | 各テストケース実行前にデータベースに登録する場合は、同じシート内に記載したデータのグループIDを記載する[1]。データの投入は自動テストフレーム ワークにより行われる。 | |
| setUpFile | 各テストケース実行前に入力用ファイルを作成する場合は、同じシート内に記載したデータのグループIDを記載する[1]。ファイルの作成は自動テストフレーム ワークにより行われる。 | |
| expectedFile | 出力ファイルの内容を比較する場合、期待するファイルのグループIDを記載する[1]。 | |
| expectedTable | データベースの内容を比較する場合、期待するテーブルのグループIDを記載する[1]。 | |
| expectedLog | 期待するログメッセージを記載したLIST_MAPデータのIDを記載する。 そのログメッセージが実際に出力されたかどうか、自動テストフレームワークにて検証される。 (『ログの結果検証』を参照) | |
| diConfig | バッチを実行する際のコンポーネント設定ファイルへのパスを記載する。 (コマンドライン引数を参照) | 必須 |
| requestPath | バッチを実行する際のリクエストパスを記載する。 (コマンドライン引数を参照) | 必須 |
| userId | バッチ実行ユーザIDを記載する。 (コマンドライン引数を参照) | 必須 |
| expectedMessage | メッセージ同期送信を行う場合、期待する要求電文の グループIDを記載する。メッセージの作成は自動テストフレームワークにより行われる。 | |
| responseMessage | メッセージ同期送信を行う場合、返却する応答電文の グループIDを記載する。メッセージの作成は自動テストフレームワークにより行われる。 | |
| expectedMessageByClient | HTTPメッセージ同期送信を行う場合、期待する要求電文の グループIDを記載する。メッセージの作成は自動テストフレームワークにより行われる。 | |
| responseMessageByClient | HTTPメッセージ同期送信を行う場合、返却する応答電文の グループIDを記載する。メッセージの作成は自動テストフレームワークにより行われる。 |
| [1] | (1, 2, 3, 4) デフォルトのグループIDを使用したい（グループIDを使わない）場合は、defaultと記載する。 デフォルトのグループIDと個別のグループを併用することも可能である。 両方のデータが混在した場合、デフォルトのグループIDのデータとグループID指定のデータ両方が有効になる。 |
3.1.10.3.2.1. コマンドライン引数¶
テストデータで、コマンドライン引数を指定する方法を説明する。
バッチ起動時の引数を指定するには、args[n]（添字nは0以上の整数）という形式でカラムを追加する。
no case ... args[0] args[1] args[2] 1 xxxのケース ... 第1引数 第2引数 第3引数 重要
添字nは連続した整数でなければならない。
テストケース一覧に上記以外のカラムを追加すると、そのカラムはコマンドラインオプションとみなされる。
例えば、テストケース一覧に以下のようなカラムがあるとすると、
no case ... paramA paramB 1 xxxのケース ... valueA valueB
-paramA=valueA -paramB=valueB
というコマンドラインオプションを指定したことになる。
3.1.10.3.3. 各種準備データ¶
テスト実施に際して必要となる各種準備データの記述方法を説明する。 バッチでは、データベース、入力ファイルの準備を行う。
3.1.10.3.3.2. 固定長ファイルの準備¶
テストデータに固定長ファイルの情報を記載しておくと、自動テストフレームワークがテスト実行前にファイルを作成する。 以下の書式で記述する。
SETUP_FIXED[グループID]=ファイルパス
ディレクティブ行
| レコード種別 | フィールド名称(1) | フィールド名称(2) | ... [2] |
| データ型(1) | データ型(2) | ... | |
| フィールド長(1) | フィールド長(2) | ... | |
| データ(1-1) | データ(2-1) | ... | |
| データ(1-2) | データ(2-2) | ... | |
| ... [3] | ... | ... |
| [2] | これより右側は、同様にフィールドの数だけ続いていく。 |
| [3] | これより下側は、同様にデータの数だけ続いていく。 |
| 名称 | 説明 |
|---|---|
| グループID | グループIDを指定する。テストケース一覧のsetUpFileに記載されたグループIDと紐付けられる。 |
| ファイルパス | カレントディレクトリからのファイルパスを記載する（ファイル名を含む）。 |
| ディレクティブ行 [4] | ディレクティブを記載する。ディレクティブ名のセルの右のセルに設定値を記載する（複数行指定可）。 |
| レコード種別 | レコード種別を記載する。マルチレイアウトの場合は、この記述を連続で記載する。 |
| フィールド名称 | フィールド名称を記載する。フィールドの数だけ記載する。 |
| データ型 | そのフィールドのデータ型を記載する。フィールドの数だけ記載する。 データ型は「半角英字」のように日本語名称で記述する。 フォーマット定義ファイル上のデータ型と日本語名称のデータ型のマッピングは、 BasicDataTypeMapping のメンバ変数DEFAULT_TABLEを参照。 |
| フィールド長 | そのフィールドのフィールド長を記載する。フィールドの数だけ記載する。 |
| データ | そのフィールドに格納されるデータを記載する。複数レコード存在する場合は次の行に続けてデータを記載する。 |
| [4] | ディレクティブを記述する際、フォーマット定義ファイルの以下に対応する内容は記述不要である。
|
重要
ひとつのレコード種別において、フィールド名称に重複した名称は許容されない。例えば、「氏名」というフィールドが2つ以上存在してはならない。 （通常、このような場合は「本会員氏名」と「家族会員氏名」のようにユニークなフィールド名称が付与される） 異なるレコード種別間で、同一の名称が存在する場合は問題ない。 （例えばヘッダレコードとトレーラレコードにそれぞれ「件数」というフィールド名称が存在してよい）
補足
フィールド名称、データ型、フィールド長の記述は、外部インタフェース設計書からコピー＆ペーストすることで効率良く作成できる。（ペーストする際、「行列を入れ替える」オプションにチェックすること）
補足
「符号無数値」および「符号付数値」のデータ型を使用する場合、そのデータには、固定長ファイルから入力する値（固定長ファイルへ出力する値）をそのまま記載すること。 すなわち固定長ファイルにパディング文字や符号が存在する場合は、それらの記載まで行う必要がある。
以下に、データ型が符号付数値の場合に表したい値とその表現方法の例を示す。（フォーマット定義： フィールド長10桁、パディング文字‘0’、小数点必要、符号位置固定、正の符号不要）
表したい数値 テストデータ上の記載 12345 0000012345 -12.34 -000012.34
「符号無数値」および「符号付数値」をテストデータとして使用する場合、テスト用のデータタイプを設定する必要がある。
以下に設定例を参照し、テスト用の設定を追加すること。
<component name="fixedLengthConvertorSetting"
class="nablarch.core.dataformat.convertor.FixedLengthConvertorSetting">
<property name="convertorTable">
<map>
<!--
デフォルトの設定
デフォルトの設定を行わないと、ここで設定した値でデフォルト設定が上書きされるため注意すること。
-->
<entry key="X" value="nablarch.core.dataformat.convertor.datatype.SingleByteCharacterString"/>
<entry key="N" value="nablarch.core.dataformat.convertor.datatype.DoubleByteCharacterString"/>
<entry key="XN" value="nablarch.core.dataformat.convertor.datatype.ByteStreamDataString"/>
<entry key="Z" value="nablarch.core.dataformat.convertor.datatype.ZonedDecimal"/>
<entry key="SZ" value="nablarch.core.dataformat.convertor.datatype.SignedZonedDecimal"/>
<entry key="P" value="nablarch.core.dataformat.convertor.datatype.PackedDecimal"/>
<entry key="SP" value="nablarch.core.dataformat.convertor.datatype.SignedPackedDecimal"/>
<entry key="B" value="nablarch.core.dataformat.convertor.datatype.Bytes"/>
<entry key="X9" value="nablarch.core.dataformat.convertor.datatype.NumberStringDecimal"/>
<entry key="SX9" value="nablarch.core.dataformat.convertor.datatype.SignedNumberStringDecimal"/>
<entry key="pad" value="nablarch.core.dataformat.convertor.value.Padding"/>
<entry key="encoding" value="nablarch.core.dataformat.convertor.value.UseEncoding"/>
<entry key="_LITERAL_" value="nablarch.core.dataformat.convertor.value.DefaultValue"/>
<entry key="number" value="nablarch.core.dataformat.convertor.value.NumberString"/>
<entry key="signed_number" value="nablarch.core.dataformat.convertor.value.SignedNumberString"/>
<!--
テスト用のデータタイプの設定
符号無数値(X9)->TEST_X9:nablarch.test.core.file.StringDataType
符号有数値(SX9)->TEST_SX9:nablarch.test.core.file.StringDataType
-->
<entry key="TEST_X9" value="nablarch.test.core.file.StringDataType"/>
<entry key="TEST_SX9" value="nablarch.test.core.file.StringDataType"/>
</map>
</property>
</component>
- 具体例を示す。このファイルは以下のレコードで構成されている。
- ヘッダレコード１件
- データレコード２件
- トレーラレコード１件
- エンドレコード１件
文字コードはWindows-31J、レコード区切り文字はCRLFである。
SETUP_FIXED=work/members.txt
| text-encoding | Windows-31J | ||
| record-separator | CRLF | ||
| ヘッダ | レコード区分 | FILLER | |
| 半角数字 | 半角 | ||
| 1 | 10 | ||
| 0 | |||
| データ | レコード区分 | 会員番号 | 入会日 |
| 半角数字 | 半角数字 | 半角数字 | |
| 1 | 10 | 8 | |
| 1 | 0000000001 | 20100101 | |
| 1 | 0000000002 | 20100102 | |
| トレーラ | レコード区分 | レコード件数 | FILLER |
| 半角数字 | 数値 | 半角 | |
| 1 | 5 | 4 | |
| 8 | 2 | ||
| エンド | レコード区分 | FILLER | |
| 半角数字 | 半角 | ||
| 1 | 10 | ||
| 9 | |||
3.1.10.3.3.3. 可変長ファイル（CSVファイル）の準備¶
可変長ファイル（CSVファイル）の準備も、固定長とほぼ同様である。 固定長との違いは、可変長ファイルの場合はフィールド長を記載しない点である。
SETUP_VARIABLE=work/members.csv
| text-encoding | Windows-31J | ||
| record-separator | CRLF | ||
| ヘッダ | レコード区分 | ||
| 半角数字 | |||
| 0 | |||
| データ | レコード区分 | 会員番号 | 入会日 |
| 半角数字 | 半角数字 | 半角数字 | |
| 1 | 0000000001 | 20100101 | |
| 1 | 0000000002 | 20100102 | |
| トレーラ | レコード区分 | レコード件数 | |
| 半角数字 | 数値 | ||
| 8 | 2 | ||
| エンド | レコード区分 | ||
| 半角数字 | |||
| 9 | |||
補足
フィールド区切り文字を変更する場合、フィールド区切り文字を ディレクティブで明示的に指定する。例えば、区切り文字をタブにしたい（TSVファイル）場合、 以下のように、ディレクティブを指定する。
field-separator=\t
3.1.10.3.3.4. 空のファイルを定義する方法¶
準備データや期待値として空のファイル(0バイトファイル)を定義したい場合がある。
テストシート上での空ファイルの定義は、以下の例のようにディレクティブ行を定義しレコードの定義を省略することで実現出来る。
空のファイルの定義例
SETUP_VARIABLE=work/members.csv
| text-encoding | Windows-31J | ||
| record-separator | CRLF | ||
| //空ファイル | |||
3.1.10.3.4. 各種期待値¶
検索結果、データベースを期待値と比較する場合は、 それぞれのデータとテストケース一覧とをIDで紐付けする。
3.1.10.3.4.2. 期待する固定長ファイル¶
テスト対象バッチが出力する固定長ファイルをアサートする。
準備データの場合、データタイプが、SETUP_FIXEDであったが、 期待値を記述する場合は、EXPECTED_FIXEDとなる。
その他のテストデータの記述方法は、準備データと同様である。固定長ファイルの準備を参照。
3.1.10.3.4.3. 期待する可変長ファイル¶
テスト対象バッチが出力する可変長ファイルをアサートする。
準備データの場合、データタイプが、SETUP_VARIABLEであったが、 期待値を記述する場合は、EXPECTED_VARIABLEとなる。
その他のテストデータの記述方法は、準備データと同様である。可変長ファイル（CSVファイル）の準備を参照。
3.1.10.4. テストメソッドの書き方¶
3.1.10.4.1. スーパクラスについて¶
BatchRequestTestSupportクラスを継承する。
このクラスでは、準備したテストデータを元に以下の手順でリクエスト単体テストを実行する。
3.1.10.4.3. スーパクラスのメソッド呼び出し¶
テストメソッド内で、スーパクラスの以下のいずれかのメソッドを呼び出す。
- void execute()
- void execute(String sheetName)
通常の場合、execute()を使用する。引数ありのexecuteメソッドでは、テストデータのシート名を指定できるが、 通常、テストシート名とテストメソッド名は同一である。引数なしのexecuteメソッドを使用すると、テストデータのシート名に テストメソッド名を指定したのと同じ動作となる。
@Test
public void testResigster() {
execute(); // 【説明】execute("testRegisterUser") と等価
}
3.1.10.5. テスト起動方法¶
クラス単体テストと同様。通常のJUnitテストと同じように実行する。
3.1.10.6. テスト結果検証¶
3.1.10.6.1. データベースの結果検証¶
テストケース一覧のexpectedTable欄にグループIDを記載することにより、 そのグループIDのテストデータで実際のファイル出力結果を確認することができる。
3.1.10.6.2. ファイルの結果検証¶
テストケース一覧のexpectedFile欄にグループIDを記載することにより、 そのグループIDのテストデータで実際のファイル出力結果を確認することができる。
ファイル期待値の記述方法は、準備データの記述方法とほぼ同じである。 IDの記述方法だけが異なる。 ファイル種別ごとの記述方法を以下に示す。
| ファイル種別 | グループID指定なし | グループIDを指定ありの場合 |
|---|---|---|
| 固定長ファイル | EXPECTED_FIXED=比較対象ファイルのパス |
EXPECTED_FIXED[グループID]=比較対象ファイルのパス |
| 可変長ファイル | EXPECTED_VARIABLE=比較対象ファイルのパス |
EXPECTED_VARIABLE[グループID]=比較対象ファイルのパス |
3.1.10.6.3. ログの結果検証¶
テストケース一覧のexpectedLog欄にグループIDを記載することにより、 そのグループIDのテストデータで実際のログ出力結果を確認することができる。
以下の内容を記載する。
| カラム名 | 内容 |
|---|---|
| logLevel | 期待するログのログレベル |
| messageN[5] | 期待するログに含まれる文言 |
| [5] | Nは1以上の整数を指定することで複数の値（連続する値であること） (例) messsage1, message2... |
補足
これらの条件は全てAND条件である。 以下のような場合には、期待するログが出力されたとは見なされない。
- 期待する文言はログ出力されているが、ログレベルが期待通りでない場合
- ログレベルは合致しているが、期待する文言で、ログ出力されていないものが１つでもある場合
具体例を以下に示す。
以下の例では、２種類のログ出力を期待している。
LIST_MAP=expectedLogMessages
| logLevel | message1 | message2 | message3 |
|---|---|---|---|
| INFO | NB11AA0101 | 処理を開始します。 | 会員ID=[0001] |
| FATAL | NB11AA0109 | エラーが発生しました。 |
重要
expectedLog欄にグループIDを記載した場合には、必ず期待するメッセージを1行以上設定すること。 期待するメッセージが設定されていない場合(期待するメッセージが0行の場合)や、expectedLog欄に記載されたグループIDに紐付く LIST_MAP要素が存在しない場合には、本フレームワークは期待値の準備が不足していると判断し例外を送出する。