内容

結合テスト仕様書を書く際に、単体テストとの違いが分からなく上司と1時間程話した備忘録

#はじめに
・初めてQiita書きました
・備忘録

#システム構造

私が担当しているシステムの構造は上記のような感じ。

メニュー画面からそれぞれの機能に画面遷移が行うことができ、
それぞれの画面にボタンが用意されている。
そのボタンを押下すると登録されているプログラムが動作するようになっている。

ボタンの中のプログラムはいくつかのクラスファイルから成り立っており、
順番に動作していく。

例)
1.確認ダイアログ出力クラス
2.業務ロジッククラス
3.作業ログ出力クラス
※上から順に実行されていく

それぞれの機能を使う順序としては
機能A　→　機能B　→　機能C　と順番にデータを渡すとします。

・機能Aにて作業用データを登録
・機能Bにて作業用データを更新
・機能Cにて機能Bによって加工された最終的なデータを別テーブルに登録
現在時刻を表示する

(機能Cだけ特別に2つ機能を持たせました)

###単体テストってどこまで?
この場合、私の認識だと**「ボタンを押下した時の結果」**が単体テストの範囲
だと考えています。

ここでは機能Cを例にテストパターンを書いてみます。

No	テストケース	結果
1	ボタンAを押下する	レコードが作成される
2	ボタンBを押下する	現在時刻を表示する

####こんな仕様があった時はどのようにテストケースを記載する?
仕様: ステータスが「bad_state」の時、レコードは作成せずエラーとする

そんな時はこんなケースを追加します。

No	テストケース	結果
1	ボタンAを押下する	レコードが作成される
2	ステータスが「bad_state」の時、ボタンAを押下する	エラーメッセージを表示する
3	ボタンBを押下する	現在時刻を表示する

これでばっちりです。健全なステータスのレコードしか登録できなくなりました。

###じゃあ結合テストの範囲って?
この場合、私の認識だと**「機能間でのデータのやり取り」**がテストの範囲かと
考えています。

例として機能Bと機能Cを題材に挙げてみます。

【前提条件】
・機能Bではステータスを「bad_state」に変更します。
・機能Cではステータスが「bad_state」以外のものを登録できるものとします

運用としては、機能Bでデータを更新して機能Cでデータを登録するので

この場合、

No	テストケース	結果
1	機能Bにて更新されたレコードを選択し、ボタンAを押下する	エラーメッセージを表示する

こんな感じのテストケースが出来上がりました。

そうですね、機能Bでデータを更新したらステータスが「bad_state」になるので
機能Cはエラーを出す羽目になります。

(ちなみにここでは「現在時刻を表示する」というテストケースは記載しません。
　何故なら機能C単体で完結している内容であり、機能Bと関係性が無い為です)

###あれ、これ単体テストと確認している内容が被っているのでは？
確かに。
「ステータスが「bad_state」の時、ボタンAを押下する」という動作には変わりがありません。

そうなんです、ほぼ同じなんです。ですが1割だけ違います。
その1割は**「機能Bによって更新されたデータを対象にしているか」**という点です。

機能Cの単体テスト、結合テストどちらともステータスが「bad_state」ならエラーが出る事は
変わりません。ですが、そのデータが一つ前の機能に関わっているかがミソみたいです。

####何が違うの？
下記の点で違いが現れます。

<不整合を防ぐ>
・単体テストを行う際に、テストデータはDBを直接いじったりして自作のテストデータを作るケースがあります。そのデータだとプログラム的にあり得ない値を取るケースがあります。
そういったデータでテストしないメリットがあります。

##単体と結合の違いが分からなかった
この**「他の機能に関わっているか」**という概念が中々理解できず、結合テスト仕様書に
単体テストレベルの内容を記載しまくっていました。
ただ、この概念が理解できたので、前よりかはテストケースが書きやすくなりました。

内容は一部被る所があるかもしれないが、それが結合テストなのかと思う今日この頃でした。