質問: ### 前提・実現したいこと 結合テストについての一般常識を知りたいです。 なお、テスト対象は仮にJavaとSTSで作れるECサイト、MVCモデルとします。 まだ勉強中なため内容がふわっとしてるかもしれません。 ### 結合テストのイメージ 私は結合テストがいまいちイメージできず勉強しています。 私が調べたところ、結合テストとは以下のようなものだとイメージしました。 以下のイメージが合っているか教えてください。 * 複数モジュールの連携、また、モジュール間のインターフェイスのテスト。 →登録機能ないし画面で登録したデータを、検索機能ないし画面にて表示してみる......など。 * ホワイトボックス・テストを行わないテスト。 →サービスなどはデータが入出力されるかのみ見る。中身のロジックが正確かは考慮しない(単体テストの担保)。 * 複数の単体テストを結合したもの。また、単体テストにおけるモック、スタブ、ドライバを実装したもの。また、複数のテストケースを結合したもの。 →この場合、単体の更新機能でも結合テストになりうる。 つまり、モジュールは「リクエストを送信するビュー」、「リクエストを受信するコントローラ」、「リクエストを処理するサービス」、「リクエストを処理するDB」に分かれる。 インターフェイスは上記「ビュー」と「DB」の間の処理といえる。 * IT環境で行うもの。換言すれば、複数モジュールの連携したテストでもローカル環境なら結合テストといわない。 →これはイメージしがたい。 「登録機能ないし画面で登録したデータを、検索機能ないし画面にて表示してみる。」ことも結合テストと言えなくなる? * リクエスト~レスポンスを確認するテスト →データ登録ボタンを押して、登録しましたというメッセージが出るまで......など * ローカルとリモートの隔たりがあるテスト →ローカルから送信したデータがリモートのサーバにより更新されているかDBMSにより確認する。 あるいは、同じ画面にて、リクエストによるレスポンスが正しいか確認する。
回答: 直接の回答じゃないですが、各テスト工程で「何をすべきか」というのはプロジェクトや人によって結構解釈がブレてる事が多いので、教科書的な答え(それも大事ではありますが)を期待するよりは個別にプロマネに確認した方が良かったりします。 というのも、プロジェクトの工程の区切り方って別に正解があるわけではなく、テスト計画全体を通してどの工程でどういうテストをしてどのように品質を担保するのか、というのはマネジメントの考え方次第だったりするからです。 なので、プロマネ側であれば各工程でどういうテストを行うべきか、は自分が線引してちゃんとメンバーに伝える必要がありますし、メンバー側であればその考え方をちゃんと理解している必要があります。 教科書的な線引きをして「これが結合テストだ」という事に凝り固まってしまうと、そのコミュニケーションを疎かにしてしまい、結果として抜けや漏れが生じる危険があります。 テストは、その定義や方法自体が目的ではなく、最終的にプロダクトの品質を保証する事を目的にしているはずです。この「品質」には一応規格があって、割とちゃんと分類できます。 で、例えば > > 同じ画面にて、リクエストによるレスポンスが正しいか確認する。 > > > という内容について、これを「結合テストである」と定義したとします。 しかし、この「正しい」とは何でしょうか? 機能性の話であれば、リクエストをして30秒後に期待した値が取れれば「正しい」となります。 でも、本来は「3秒未満」で終わる事が期待されている(非機能要件)処理であれば「正しくない」となります。 このように、前提をきちんと決めずに「〇〇だからこのテスト」みたいな決め打ちは結構無理があるわけです。 非機能要件はシステムテストで確認することも多いですが、後の工程で発見される不具合ほど手戻りの工数が多くなるため、早期のテストでちゃんと確認するのが理想ではあります。でも、そもそも開発期間に余裕があったり、規模の小さいプロジェクトであれば、そこはあんまり問題にならなかったりもします。 要するにケースバイケースで判断する必要がどうしても残るので、あんまり頭でっかちになるのはよろしくないのかな、という意見です。 あなたがどう考えるか、は重要です。 テスト工程のなかで、挙げられた項目はどこでテストするべきか、はよく悩んで決めてください。 でも、それは万人にとっての絶対ではない、という事も肝に銘じておきましょう。