ユニットテストについて考えてみた。

ユニットテストによる品質向上について考える機会があったので、
自分の中のユニットテスト像を再確認の意味で文章に起こしてみました。

■ ユニットテストを定義してみる。

ユニットテストとは、
  1. 要件を実現するための構築対象の全体のうち、
  2. 業務ロジックを提供するクラス郡のAPI(publicメソッド)を最小単位とし、
  3. それぞれが独立して期待した通りに動作することを保証すること。
と定義する。

1. スコープ

対象はシステム開発時のモジュール全体としました。
(最終的にすべてテスト対象となる)

システム開発を行う上では、必ずしも一つの言語で構築されるわけではないと思います。
たとえば、
javaでWabサービスを作りつつ、バッチ処理をシェルスクリプトで記載したり、ExcelマクロでCSV作成ツールを作ったり、など。

2. 抽出

前項の集合からユニットテストを行う上で必要な個所はどこか?またその対象は?ということです。

基本的にService/Business層(J2EE パターン)やModel層(MVCフレームワーク)を対象とします。
publicメソッドに限定しましたが、privateやprotectedもできれば作るべきだと思います。
ただ、
・工数が限られてきた場合の優先度としてはpublicだけでも通してほしい
・publicを通すことである程度カバーできる
ので敢えて外しました。

3. 目的

ホワイトボックステストですね。
気持ちとしては、バグを見つけるためというよりはメソッドの振る舞いを確認するという意味合いが強いかなと。

■ ユニットテストと単体テスト

と改めてまとめると、「本当にユニットテストだけで単体バグをつぶせるの?」って時に、
そもそも単体テストとユニットテストの違いってなんだろうと思ってググったら下記の記事がありました。

ユニットテストと単体テストは違うという話

元記事から自分の理解を要約すると
「ユニットテストでプログラムの振る舞いの保証、単体テストはバグ出しをする。」
となりました。

今までの考えは
  実装 ⇒ ユニットテスト/単体テスト
のような工程で考えてましたが、
  実装/ユニットテスト ⇒ 単体テスト
とした方がしっくりくる気がします。
(工数として実装に寄せるか単体テストに寄せるかは難しいところ。。。。)

■ まとめ

品質を守るためには、
実装者がユニットテストで動作を確認したモジュール群を単体テストでバグ出しをする。
が理想的な流れだと思います。

ただし、両方やるにはどうしても工数が足りなくるのが現実。
また、両者の役割が違うので、どちらか(特にユニットテスト側)に寄せようとするとどこかで無理が生じるのかなと。

個人的には一度作ってしまえばリグレッションテストが楽なユニットクラスでカバーしたいですが、
ユニットテストはコーディングの延長なのでメンバーのスキルに依存する部分が大きいので、
どちらかを選ぶのであれば項目書ベースの単体テストの方が品質は守れる気がします。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る