リクエスト単体テストの実施方法(同期応答メッセージ送信処理)¶
出力ライブラリ(同期応答メッセージ送信処理)の構造とテスト範囲¶
同期応答メッセージ送信処理のリクエスト単体テストは、当該処理に付与されたリクエストID[1]単位で行う。
| [1] | ここで扱うリクエストIDとは、メッセージを送信する相手先システムの機能を一意に識別するために定義するIDのことを指すものであり、 ウェブアプリケーションやバッチ処理で使用するリクエストIDとは意味が異なる点に注意すること。 このリクエストIDにもとづき、要求電文および応答電文のフォーマット、送信キュー名、受信キュー名が決定する。 |
※本項では、Actionがキューへ送信するメッセージのことを「要求電文」、Actionがキューから受信するメッセージのことを「応答電文」と称す。
リクエスト単体テスト実施時のイメージを以下に示す。
補足
自動テストフレームワークは、「送信キュー」「受信キュー」を使用せず、キューの手前で要求電文のアサートおよび、応答電文を生成する。 このため、特別なミドルウェアのインストールや環境設定は不要である。
本自動テストフレームワークを用いて実施する同期応答メッセージ送信処理のリクエスト単体テストの特色と利点を以下に挙げる。
- 書きやすいテストデータ
電文レイアウトはフィールド長が固定されていることがほとんどであり、固定長ファイル同様に テストデータとしては記載しにくいが、本自動テストフレームワークでは、 Excelファイルを使用することで、外部インターフェース設計書のフォーマット定義に沿って テストデータを記載できる。
また、同期応答メッセージ送信処理用のテストデータ書式が提供されており、これに準拠することで テストデータを容易に作成することができる。 これらの特徴により、テストデータが作りやすくかつ保守しやすいものとなっている。
- メッセージ同期送信処理についてのテストコードを記載する必要がない
テストデータ（要求電文の期待値および応答電文）はExcelに記載することができ、自動テストフレームワークはそのテストデータをもとに要求電文のアサートおよび応答電文の返却を自動的に行う。
このような典型的な定型処理を実装したスーパークラスが提供されており、これを使用することで、 テスト準備、テスト対象の実行、テスト結果確認が可能である。 これにより、テストデータのみで、ほぼコーディングなしでテストが実行可能である。
テストの実施方法¶
同期応答メッセージ送信処理のテストは、ウェブアプリケーションやバッチ処理などのテスト方式を踏襲して行われる。 テストクラスの書き方や各種準備データの準備方法については、これらのテストの実施方法を参照すること。
本項では、同期応答メッセージ送信処理個有の実施方法についてのみ解説する。
テストデータの書き方¶
テストデータを記載したExcelファイルは、クラス単体テストと同様にテストソースコードと同じディレクトリに同じ名前で格納する（拡張子のみ異なる）。
テストデータの記述方法詳細については、「Excelによるテストデータ記述」を参照。
要求電文の期待値および、返却する応答電文（レスポンスメッセージ）の準備¶
同期応答メッセージ送信処理を行う場合、リクエストIDごとに、要求電文および応答電文のヘッダ部とボディ部のフォーマットおよび、データを定義する。
テストケースと要求電文の期待値および応答電文は、グループIDで対応付ける。 具体的には、テストケースのexpectedMessageおよびresponseMessageのフィールドに記載されたグループIDが、 対応する識別子を持つ表と対応することとなる。
なお、テストケース一覧にexpectedMessageおよびresponseMessageの欄がない場合には検証が行われない。 また空欄で、かつメッセージ同期送信処理が行われた場合には、テストが失敗する。 メッセージ同期送信処理を行う場合は、expectedMessageおよびresponseMessageを必ず記載すること。
１つのテストケースで、同一グループIDかつ同一リクエストIDを持った電文が複数件送信される場合は、その件数分要求電文および応答電文のデータ行を記載すること。noの列の順番（連番）は送信される順番に一致する。
- テストケースの書き方についての詳細は、以下を参照すること。
以下に、実際にExcelで書かれたテストデータを示す。（グループIDの関連も示す）
補足
Nablarchが標準で提供する同期応答メッセージ送信機能では、要求電文と応答電文のヘッダ部は共通のフォーマットを使用するので、 テストデータも同様にヘッダ部のフォーマット定義をリクエスト単位で統一すること。 ボディ部については、要求電文と応答電文で異なるフォーマットを定義できる。
要求電文の期待値および、返却する応答電文の表は以下の書式で記載する。
| 識別子 | |||
| ディレクティブ行 | ディレクティブの設定値 | ||
| ... [2] | ... | ||
| no | フィールド名称(1) | フィールド名称(2) | ... [3] |
| データ型(1) | データ型(2) | ... | |
| フィールド長(1) | フィールド長(2) | ... | |
| データ(1-1) | データ(2-1) | ... | |
| データ(1-2) | データ(2-2) | ... | |
| ... [4] | ... | ... | |
| [2] | これより下側は、同様にディレクティブの数だけ続いていく。 |
| [3] | これより右側は、同様にフィールドの数だけ続いていく。 |
| [4] | これより下側は、同様にデータの数だけ続いていく。 |
| 名称 | 説明 |
|---|---|
| 識別子 | 電文の種類を示すIDを指定する。本項目が、テストケース一覧のexpectedMessageおよびresponseMessageに記載されたグループIDと紐付けられる。 識別子の書式を以下に示す。
|
| ディレクティブ行 [5] | ディレクティブを記載する。ディレクティブ名のセルの右のセルに設定値を記載する（複数行指定可）。 |
| no | ディレクティブ行の下の行には必ず「no」を記載する。 |
| フィールド名称 | フィールド名称を記載する。フィールドの数だけ記載する。 |
| データ型 | そのフィールドのデータ型を記載する。フィールドの数だけ記載する。 データ型は「半角英字」のように日本語名称で記述する。 フォーマット定義ファイル上のデータ型と日本語名称のデータ型のマッピングは、 BasicDataTypeMapping のメンバ変数DEFAULT_TABLEを参照。 |
| フィールド長 | そのフィールドのフィールド長を記載する。フィールドの数だけ記載する。 |
| データ | そのフィールドに格納されるデータを記載する。複数レコード存在する場合は次の行に続けてデータを記載する。 そのフィールドに格納されるデータを記載する。1テストケースにおいて同一リクエストIDで複数回同期送信する場合は、次の行に続けてデータを記載する。 |
| [5] | ディレクティブを記述する際、フォーマット定義ファイルの以下に対応する内容は記述不要である。
|
重要
フィールド名称に重複した名称は許容されない。例えば、「氏名」というフィールドが2つ以上存在してはならない。 （通常、このような場合は「本会員氏名」と「家族会員氏名」のようにユニークなフィールド名称が付与される）
補足
フィールド名称、データ型、フィールド長の記述は、外部インタフェース設計書からコピー＆ペーストすることで効率良く作成できる。（ペーストする際、「行列を入れ替える」オプションにチェックすること）
以下に具体的な要求電文の本文の期待値の記載例を示す。
要求電文のヘッダの期待値および応答電文の本文・ヘッダについても、識別子を除く部分についてはここで記載する要求電文の本文の期待値と同様の記載方法となる。
この例では、以下の仕様を満たす要求電文が送信されることを期待している。
- リクエストIDは
RM21AA0104 - 文字コードは
Windows-31J - レコード区切り文字は
CRLF - レコード区分は
1、ユーザIDは0000000001、ログインIDはnabura
重要
要求電文に複数のレコードが存在する場合、以下の様に1つのヘッダに複数の業務データを記載したくなる。
- ヘッダ
- 業務データ(1レコード目)
- 業務データ(2レコード目)
- 業務データ(3レコード目)
しかし、自動テストフレームワークでは、以下の様にヘッダとレコードを交互に記載する必要がある。 ヘッダを重複して定義しなかった場合、業務データとヘッダの数が一致しないためアサーションエラーが発生する。
- ヘッダ
- 業務データ(1レコード目)
- ヘッダ
- 業務データ(2レコード目)
- ヘッダ
- 業務データ(3レコード目)
複数回電文を送信する場合のテストは、テスティングフレームワークの以下の仕様に注意をして記述すること。
- 同一データタイプ(以下の例では
RESPONSE_HEADER_MESSAGESとRESPONSE_BODY_MESSAGES)は、それぞれ、まとめて記述する。詳細は、 一つのシートに複数テストケースのデータを記載したい及び、 複数のデータタイプ使用時はデータタイプごとにまとめてデータを記述するを参照。 - 同一リクエストIDの電文については、noの値を変えてまとめて記述する。
以下に、複数回メッセージを送信する場合の要求電文の本文の期待値の記載例を示す。
補足
送信対象のリクエストIDが複数存在する場合、送信順のテストは不可能である。上記の例の場合、 ProjectInsertMessage より先に、 ProjectInsert2Messag が送信された場合であってもテストは成功となる。
障害系のテスト¶
応答電文の表に「errorMode:」から始まる特定の値を設定することで、障害系のテストを行うことができる[6]。
以下に、設定値と、障害系のテストの対応を示す。
最初のフィールドに設定する値 障害内容 自動テストフレームワークの動作 errorMode:timeoutメッセージ送信中にタイムアウトエラーが発生する場合のテスト MessageSendSyncTimeoutException (MessagingException のサブクラス)を送出する。 errorMode:msgExceptionメッセージ送受信エラーが発生する場合のテスト MessagingException をスローする。
この値は、応答電文の表のヘッダおよび本文両方の、「no」を除く最初のフィールドに記載すること。
Excelで設定する場合のイメージを以下に示す。
| [6] | 業務アクション内で、明示的に MessagingException を制御していないのであれば、 個別のリクエスト単体テストにおいて障害系のテストを行う必要は無い。 |