ひよっこ。

I want to…

単体テストの品質分析に関する妄想(途中)

Posted by hikaruworld : 2011 4月 3

単体テストの品質分析に関して、ちょっとまじめに考えている(現在進行形)。
(普段何気なくやってる事を整理しただけなので、別にたいしたことを書いている訳ではない)
単体テストで品質分析を行う場合、
  • プロダクトコードの検証
  • テストコードの検証
の二つの視点で考えるようにしている。

プロダクトコードの検証

コードフォーマットに起因する問題分析

実施方法::CheckStyle,CPDなどを利用する(Javaの場合)
目的::読みやすいクリーンなコードを維持する事で、読み違いやミスなどを防止する。

フォーマット規約に反していないか、冗長なコードがないか、重複したコードがないかを検証する。
問題があった場合に、対象のコードに対応が必要かどうかを検討する。

プログラムコード構造に関する問題分析

実施方法::FindBugs,PMDなどを利用する。
目的::実装中の考慮漏れをコードの構成側から分析する。

構造上に潜在的に危険なコードがないか検証する。
問題があった場合は、問題の大きさを考慮して対応が必要かどうかを検討する。
ただし、これらのツールは問題の大小に応じて修正するかどうかを検討する場合が多い。

#  FindBusgとPMDを別途あげているのは、これらのコード解析方法が異なるため。
# どうせ機械的に実行する以上、いろんな観点から分析できるようにしておく。

テストコードの検証

単体テスト自体の実行のタイミングはSCMへのコミット単位となっている。
そのためテストコードの検証は開発作業の流れの中に取り込む形で考えるため、
以下のような手順で行う。

  1. TDDを用いて、プログラムのクラス、メソッド単位で、仕様が網羅されているか、
    異常系の例外ケースを考えているか考慮しながら設計(テストケース)と実装を行う。
  2. 実装後にカバレッジを確認し漏れている部分を確認する。
  3. 漏れている部分の内、構造上網羅していなければまずい部分に関してはテストケースを追加する。

# イメージ的には、ブラックボックス(1) -> ホワイトボックス(2)というイメージ。ざっと絵を書いてみた。

リグレッションが発生した場合は、以下の点を考慮しながら確認を行う。
なお、リグレッションが発生するタイミングはテストコードの実行されるタイミング=SCMコミット時である。

  1. 仕様が追加ないしは、変更されたことに起因するリグレッションかどうかを確認する。
  2. 実装した内容に問題があったことに起因するリグレッションかどうかを確認する。
  3. 1の場合は、仕様網羅性を考慮してテストケースの確認を行う。
  4. 2.の場合は、構造網羅性を考慮してテストケースの確認を行う。

仕様網羅率を目的とした検証

プログラムのメソッドレベルのI/Oレベルで、仕様を網羅する形でテストコードが実装されていることの検証を行う。
観点としては、これらの項目がテストケースとして加味されていることに観点を当てる。

  • 同値検証
  • 境界値検証
  • 異常系の例外ケース

構造網羅率を目的とした検証

カバレッジレポートを確認しながら、構造上の漏れがないことを検証する。
実行されていないプロダクトコードに関しては、必要性の有無を考慮した上で、
対応したテストコードの実装を行うか検討を行う。

  • 命令網羅率が漏れなく網羅されていること
  • 分岐網羅率が漏れなく網羅されていること

なお、構造網羅率は実装と効果に関するトレードオフを考える必要がある。
たとえばPOJOなクラスのgetter/setter、発生し得ない例外など明らかに不要なテストもあるので、
そこにパワーを使うくらいなら、プライオリティの高い複雑な共通部などに注力した方がよい。

網羅されていない部分に関して

ユニットテストでの実装可能性を考慮する。
実装内容によっては非常に困難なため、手動テスト(デバッグなどブレークポイントを利用した検証)の検討を行う。
実装可能であれば、処理が漏れている部分に関しては追加のテストを実装する。
なお、この際プロダクトコードを変更する事でテストが容易なようであれば、修正を検討する。

修正範囲に関する検証

実装が追加されたコード、削除されたプロダクトコードに関して、
テストコードの修正も適切に行われているかどうかを検証する。
基本的にはプロダクトコードよりもテストコードを先に書いている以上、基本発生しない。
但し、追加されたプロダクトコードによって仕様網羅率が変更される可能性があるため、検証を行う必要がある。

リグレッションに関する検証

テストコードの実行結果からリグレッションの有無、テストの失敗が頻発してる部分をを検証する。
テストコードの実行履歴に関しては、コミット単位で実行されるユニットテストケース履歴から検証する。
特に以下のようなリグレッションが発生した場合は焦点を当ててみる事。
  • ユニットテストの継続的な失敗が発生している場合。
  • リグレッションが発生している場合(修正したテストケース以外がリグレッションしている場合)
  • インターフェイス層を超えた形でエラーが失敗しているケース

層別の公開インターフェイスの変更に伴う検証

インターフェイスが変更されている場合は影響が多きくなるため、整合性に問題がないか参照部分の検証を行う。

おまけ

単体テストと結合テストを絡める形で網羅できればいいというのが実は本音。
品質分析をプログラミングテスト工程!の最後にやらなきゃ行けないというのはちょっと理解できない。CIのタイミングがベターだと思う。

etc…

以上です。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

 
%d人のブロガーが「いいね」をつけました。