改修のテストはどこまでやる？単体・結合・手動の範囲を決める例

改修した箇所の単体テストは通った。でも、画面やDBまで全部試すべきなのか、どこを省いてよいのか迷う。テストの範囲は、変更した行数やケース数だけでは決まりません。起きてほしくない失敗を挙げ、その失敗を見つけられる境界で確認するのが基本です。

この記事では架空の問い合わせ管理を使い、入力、権限・状態、DB検索の3種類の改修を比較します。「何を試すか」だけでなく、「その確認では何が分からないか」も残すことを目指します。

確認したい失敗からテスト範囲を選ぶ

題材は、件名が必須で1〜100文字、下書き・受付済み・対応中・完了の状態を持ち、投稿者と担当者がいる問い合わせ管理です。次の3つを、それぞれ独立した架空の改修として考えます。

一つ目は、件名が不正なときの入力エラー表示を整える変更。二つ目は、受付済みから対応中へ進める「対応開始」を現在の担当者だけに許可する変更。三つ目は、一覧に「自分が担当する問い合わせ」の検索条件を追加する変更です。

同じ問い合わせ機能でも、見つけたい不具合が違います。入力メッセージの表示漏れ、権限のない更新、他人の問い合わせの混入を、同じテストのセットだけで十分に確認できるとは限りません。

まず、チームで使うテストの境界を揃える

「単体」「結合」の呼び方はチームごとに揺れます。名称だけで合意せず、実物を使うものと置き換えるものを明記します。この記事では、単体は業務判定などを狭い範囲で確認するもの、結合はControllerと変換処理、Repositoryと実DBなどのつながりを確認するものとして扱います。

また、手動はテストを実施する方法であり、単体・結合と同じ分類軸ではありません。画面操作を手動で試す場合も、自動化する場合もあります。ISTQB Foundation Levelシラバスの2.2節は、テストレベルや回帰確認を整理するときの参照先です。

この区別が曖昧だと、「結合テスト済み」と聞いた相手が実DBまで試したと思っていたのに、実際はRepositoryをモックしていた、といったすれ違いが起きます。報告では「Controllerは実物、Serviceはモック、DB未接続」と書くほうが確実です。

3つの改修を、失敗と確認の組にする

以下は範囲を相談するための案です。案件の契約、障害の影響、既存の自動テストに応じて追加・調整します。

この表は「結合テストを必ず何件」のような規則ではありません。たとえば件名判定のロジックを変えず、表示文だけ変えるなら、判定のテストを大量に書き直すより、既存の判定テストを実行し、新しい表示が必要な場面を確認します。

反対に、画面の小さなボタン変更に見えても、更新APIを新設するなら権限の確認が必要です。見た目の変更量ではなく、新しく通る経路と変わる契約から判断します。

単体では、業務判定を細かく確かめる

対応開始なら、受付済み・現在の担当者という条件で成功し、投稿者だけの権限、無関係の利用者、担当者未設定、下書きや完了状態では拒否する、といった判定を狭い範囲で確認できます。短時間で繰り返せるので、条件の端や組合せを試すのに向いています。

期待結果は戻り値だけではありません。「拒否されたら保存処理を呼ばない」を確認する設計なら、その約束も試します。ただし、保存を呼ばなかったことと、本番DBで状態が変わらなかったことは、同じ証拠ではありません。別経路の更新やトランザクションの扱いは、その境界で確認します。

具体的な書き方は、ServiceをJUnit・Mockitoでテストする方法へ案内します。本記事は、そのテストがどのリスクを受け持ち、何を別の確認へ渡すかを決めるためのものです。

結合では、値が境界を越えるところを確かめる

Serviceの判定が正しくても、Controllerがログイン利用者ではなくリクエスト本文の利用者IDをそのまま渡していたら、想定した権限確認にならない可能性があります。認証された利用者から業務判定への受け渡しを、実際のアプリの構成で確認します。

MockMvcは、実HTTPサーバーを起動せずSpring MVCの処理を試すための仕組みです。Spring公式のMockMvc説明にあるとおり、どのControllerや設定を組み込むかで確認範囲が変わります。テスト名にAPIと書いてあっても、実ネットワークやブラウザを通したとは限りません。

入力エラーのケースが403や400になって予定の判定へ届かない場合は、MockMvcでPOSTが403・400になる原因を確認できます。テスト対象へ届いていないのに、期待値を現状のステータスへ合わせて通すと、確認したかった内容を失います。

DB検索を変えたなら、担当者20の行、担当者30の行、担当者なしの行を用意し、検索結果にどれが入るかを試します。組み込みDBの確認だけでは、実際のDB製品に固有のSQLや照合順序、ロックの動作まで保証できません。そこが変更点なら、対象DBの検証環境を範囲に含めます。

画面の手動確認は、利用者が完了できるかを見る

画面では、件名のエラーが該当入力の近くに出るか、入力済みの値が保持されるか、訂正して保存できるかを見ます。対応開始なら、押した後に状態表示が更新されるか、拒否されたときに何が起きたか分かるかを確認します。

ここで長い全組合せを毎回手動で繰り返す必要があるかは、既存の自動確認と相談します。狭い判定は自動テストへ任せ、画面ではつながりと利用者の操作を代表ケースで試す構成も考えられます。一方、画面表示自体が今回の主な変更なら、実際の表示を省く理由は慎重に扱います。

手動確認の記録も「問題なし」で終わらせません。環境、利用者の役割、事前状態、操作、観察した結果を残します。自動化がまだないことと、手動で何も確認しないことは別の判断です。

省く確認は、残るリスクと一緒に相談する

期限が厳しいときも、「時間がないから単体だけ」と決める前に、今回の変更で守るべきことを確認します。担当者以外の更新を防ぐ改修なら、権限と更新結果は優先度の高い確認です。表示文だけの変更なら、無関係な大量データ性能試験を毎回行う必要性は低いかもしれません。

省く場合のメモは「一覧検索は実DBで担当者別・未設定・0件を確認。表示は主要ブラウザ一つで確認予定。大量データの性能試験は今回は未実施で、応答時間の悪化は未確認。運用規模と既存計測を確認して担当リーダーが判断する」のようにします。未実施を合格に見せず、判断者と補完方法を付けます。

完了時には「変更したところが直った確認」と「周辺が壊れていない回帰確認」を分け、残る不具合や未確認を示します。ケース数や網羅率が高いことだけで、十分と断定しません。テストがどんな失敗を検出できるかが、説明の中心です。

入力と業務の境界を見直したい場合は、ControllerとServiceの入力チェックも役立ちます。テストの価値や保守性をさらに考える選書候補として、『単体テストの考え方／使い方』を出版社と実務担当の本棚で案内しています。C#例を用いる本で、JUnit入門や本人の読後書評ではありません。

本棚にはアフィリエイトリンクを含みます。本記事の範囲表は購入せずに使えます。まず今回の改修について「見つけたい失敗」を三つ書き、それぞれを何の確認で確かめるか、何が残るかを並べてみてください。