はじめに
「単体テストって、どこまでなんでしょう？」
という質問を受けました。
社内で新人さん向けにテスト勉強会をした時、うちの会社は単体テストは実装者が、結合テスト以降はテストチームがやることが多いよ、って話をしたので、自分が実装するときにどこまでテストすればいいのか気になったようでした。
- 単体テストでは単一の機能、コンポーネント、モジュールなどに対して個別にテストを行う
- 結合テストでは単体で別々にテストしたものを組み合わせ、適切に連携しているかをテストする
その時はこんな感じで説明してました。
たしかに曖昧だよな、と思ったので自分の中でも整理しなおしてみます。
実際のテストケースで考えてみる
例えば、「ログイン機能」について考えてみます。
１）入力値と結果に注目
画面にログインIDとパスワードを入力し、組み合わせがあっていればログインさせるというのは、入力に対して出力を行う一つの機能ととらえることができます。
- 画面から入力値（ID・パスワード）を受け取る
- ログイン可不可を画面に返す
かなりおおざっぱですが、これをテストケースにするなら最低限以下のようなケースが必要と考えられます。
| ケース | 期待結果 |
|---|---|
| IDとパスワードの組み合わせでログインボタンを押下する | ログイン可不可の結果を返す |
２）内部の処理に注目
内部の処理に従って、もう少し細かく分けて考えることもできます。
- 画面から入力値（ID・パスワード）を受け取って変数に入れる
- パスワードをDBに格納されている形式に合わせて暗号化する
- アカウント情報を格納しているDBに接続する
- DBに問い合わせを投げる
- 結果を受け取る
- 結果からログイン可不可を画面に返す
実際にプログラムを書く場合には、２）のように処理を分けていると思いますが、このようにプログラムの関数＝単体と解釈することもできます。
この時の粒度でテストケースを考えると以下のようになります。
| ケース | 期待結果 |
|---|---|
| 画面からの入力値 | 画面からの入力したIDとPWをそれぞれ変数に格納していること |
| PWの変換 | 受け取ったPWを暗号化して変数に格納していること |
| DB接続 | アカウント情報を格納しているDBへの接続が成功していること |
| DB問い合わせ | DBに投げている問い合わせ文が想定しているものであること |
| ････････ 等々 |
このようなケースでは個々の変数に格納されている値をデバッグツールを使って参照したり、実行内容をログに出力してみる、デバッグ用のコードを書くなど、実装の中で何をやっているかを分かったうえでテスト方法を考えてテストすることが必要になるので、実装者自身が行うことが多いです（多いだけでテストチームがやることももちろんあります）。
そしてこの２）のパターンを「単体テスト」と呼び、その後それらをまとめた機能としての動きである１）を「結合テスト」としてテストチームが実施する場合が多いように思います。
ちなみに、実装の中身のロジック等を知ったうえで行うテストを「ホワイトボックステスト」と呼び、中で何をしているかには触れすに入り口と出口だけに注目したテストを「ブラックボックステスト」と呼びます。
なので、
単体テスト ＝ ホワイトボックス ＝ 実装者が実施
結合テスト ＝ ブラックボックス ＝ テストチームが実施
みたいに解釈されることがあるんですが、実際はそうとは限りません。
（せいぜいそういう傾向が強いかな、くらい）
どこからどこまでを1つの機能（ファンクション・関数）とするかは見方によって変わってきます。そのため単体／結合の分け方や、ホワイトボックス／ブラックボックスのどちらでテストするかは固定的なものではなく、環境や目的によっても変化します。
一応、有名なV字モデルの図では単体テストは詳細設計（コンポーネント設計）をテストベースとするように書かれていますが、詳細設計をどこまで書くか、というのも組織によってブレがあるように思います。
さいごに
結局、どこまでを「単一の機能」として「単体テスト」と呼ぶかについては、はっきりした決まりがあるわけではないのだと思います。
テストする際には、プログラマとテスターが認識をそろえないとな、というコミュニケーション大事、って話に落ち着いてしまいました。（ありがち・・・）
おまけ
結合テストの後に来るのがシステムテストなわけですが、結合テストが「コンポーネントやモジュールが連携して動くか」というプログラムより？のテストであるのに対して、システムテストはシステムとして要件を満たしているのかどうか、つまり「エンドユーザーの要件にあっているかシステム全体の動きを見る」テスト、ということになります。
システムテストのテストベースが要件定義になっているのはそういうことなんですね。