テストの視点を活用した TDD アプローチの検討とその検証

SS2011での事例論文の当日スライドです。
http://sea.jp/ss2011/archives/category/accepted_papers#category_2

Transcript

1. テストの視点を活用した TDDアプローチの検討と検証 ＴＤＤ研究会 池田 暁 井芹 洋輝 太田 健一郎
2. はじめに –本報告の要点  TDD(Test Driven Development)について  Agile開発を中心に普及しているプログラミング手法  テストファーストでユニットテストを作成し，それをパ スする製品コードを追加・変更していく  TDDの課題  TDDでのテストはプログラミングのサポートが目的であり， バグ・仕様未達を網羅的に検出すると保証できない  バグ・仕様未達の網羅的な検出が必要ならば，単体テスト工程な どで別途ユニットテストを実施する必要がある．TDDでテスト工数 の削減ができず，トータル工数が上昇する可能性がある  今回の要点  本研究会では，TDDにテストの視点を導入，バグ・仕様未 達の検出に優れたTDDアプローチの検討を行った  今回はその基礎検証の報告を行う 2
3. ＴＤＤの概要  TDD[1]は下記の3ステップを繰り返してプログラミン グを進める開発手法である 1. 失敗するユニットテストを書く（Red） 2. そのテストをパスする小さなコードを書く（Green） 3. ユニットテストがパスする状態を維持しながら，コード の設計を改善する(Refactor)  3 RED GREEN REFACT OR [1] ケント・ベック 『テスト駆動開発入門』 長瀬嘉秀監訳，（株）テクノロジック アート訳，ピアソン・エデュケーション，2003年．ISBN 4894717115
4. ＴＤＤの課題  TDDのテストはプログラミングの効率化が目的．バ グ・仕様未達を網羅的に検出できると保証できない  バグ・仕様未達の網羅的な検出が必要ならば，単体テス ト工程などで別途ユニットテストを実施する必要がある． TDDでテスト工数の削減ができず，トータル工数が上昇す る可能性がある 4 開発工程(TDD) 単体テスト工程 従来のTDD 単体テスト工程の テストケース TDDの テストケース 時間
5. ＴＤＤプロセス改善のアプローチ  以下を目的にTDDにテストの視点を導入する  バグや仕様未達の検出に優れたテストをTDDの中で構築  テスト設計の作りこみ，テスト設計の保守サポートをTDDに追加  それによりTDDによる品質改善効果を向上させる．また TDDで単体テスト工程をある程度包含し，トータルの工数 削減を目指す 5 開発工程(TDD) 単体テスト工程 従来のTDD テスト視点を 加えたTDD 開発工程(TDD) 単体テスト工程の テストケース TDDの テストケース 単体テスト工程の テストケース TDDの テストケース 単体テスト工程 時間 時間
6. TDDの補強（1/2）  TDDの継続的活動  Assertファーストによる製品コードの追加・変更  リファクタリングによる製品コードの設計改善 6 Assertファースト による追加・変更 （RED→GREEN） リファクタリング （Refactor） Green RED GREEN REFACTOR
7. TDDの補強（2/2）  TDDの継続的活動として以下を意識して行う  テスト設計の作りこみ(Verify & Debug)  テストコードの設計改善(Refactor[Test]) 7 リファクタリング (Refactor[PRODUCT]) テスト設計の洗練 (VERIFY&DEBUG) RED GREEN VERIFY& DEBUG REFACTOR •TEST •PRODUCT Green Assertファースト による追加・変更 （RED→GREEN） テストコードの 設計改善 （REFACTOR[TEST]）
8. 追加するプロセス  VERIFY＆DEBUG  テスト設計を作りこむ  テストケースを追加・洗練させる（Verify）  VerifyでREDになれば修正する（Debug)  Verifyでの付属的活動  冗長なテストの削除  仕様の確保  Refactor[Test]  テストの入力値・期待値を変更せず，テストコードの記 述改善を行う  コードの記述改善でテストの堅牢製・保守性を向上させ る 8
9. テストの視点を活用するＴＤＤプロセス リファクタリング (Refactor[PRODUCT]) テスト設計の洗練 (VERIFY&DEBUG) RED GREEN VERIFY& DEBUG REFACTOR •TEST •PRODUCT Green Assertファースト による追加・変更 （RED→GREEN） テストコードの 設計改善 （REFACTOR[TEST]） 9
10. 改善したＴＤＤプロセスの検証（1/2） 項目 内容 検証の方法 例題仕様に対して開発者がTDDとテストの視点を活用したTDDでプログ ラムとテストケースを作成する．別途，テスト担当者が網羅的なテス トケースを作成する． 以下の定量的な指標を検証する 1. TDDのテストケースの網羅度の向上 A = TDDで作成したテストケース∧網羅的なテストケース B = テストの視点を活用したTDDのテストケース∧網羅的なテストケース TDDのテストケースの網羅度の向上 = B/A 2. TDDと単体テス工程のトータルの工数削減 (%) A = TDDの実施時間 B = テストの視点を活用したTDDの実施時間 X = 網羅的なテストケースの単位ケースあたりの作成時間 D = 網羅的なテストケースの個数 - TDDで作成したテスト個数 E = 網羅的なテストケースの個数 -テストの視点を活用したTDDで作成した テスト個数 トータルの工数削減 = (1 - (B + X * E) / (A + X * D)) * 100 % 10
11. 改善したＴＤＤプロセスの検証（2/2） 項目 内容 被験者 1. 開発者 4名 TDDとテストの視点を活用したTDDで問題プログラムを作成する 2. テスト担当者 2名 例題仕様対する網羅的なテストケースを作成する 前提条件 同一の例題プログラムをTDDとテストの視点を活用したTDDで作成 することになるが，テストケースの網羅度に焦点を当てるために， その際に発生する仕様に対する学習効果は検証データの計算には 加味しない 11
12. 例題仕様  以下に述べるJudgeTriangle.judgeTriangle(int x, int y, int z)というstaticメソッドとそのテストケースを作成する  Int型の引数，x, y, zはぞれぞれ三角形の三辺の長さを表すものとする  staticメソッドは三角形が以下のどれであるかを表す列挙型を返す  正三角形  二等辺三角形  不等辺三角形  三角形ではない  x = -1のような場合でも，すべて「三角形ではない」に含める  上記は以下の2つアプローチで2回実施する  TDD  テストの視点を活用したTDD  開発者  各アプローチの実施にかかった時間を記録する  テスト担当者  テストケースの作成にかかった時間を記録する 12
13. 検証結果 TDDのテストケースの網羅度の向上  テストの視点を活用することにより，TDDのテスト ケースの網羅度が平均 2.06倍向上した 13 TDD テストの視点を活用したTDD 網羅的なテスト ケース数 TDDのテストケー スの網羅度の向上 テストケー ス数 有効なテストケー ス数 テストケー ス数 有効なテストケー ス数 被験者A 8 8 14 11 16 1.375 被験者B 16 8 21 13 16 1.625 被験者C 9 6 14 12 16 2 被験者D 7 4 20 13 16 3.25 平均 10 6.5 17.25 12.25 16 2.0625
14. 検証結果 TDDと単体テスト工程のトータルの工数削減 14  テストの視点を活用することによりトータルの工数が平均 6.81%削減された（テスト設計経験者の場合21.6%削減）  被験者Aで大幅に工数が増加している理由は以下が考えられる  テスト設計に慣れておらず，テスト設計に時間がかかった  テスト設計を作りこみすぎた テスト設計 経験 TDD テストの視点を活用したTDD マスターテストケー スの単位ケースあた りの作成時間 TDDと単体テスト工 程のトータルの工数 削減 (%) TDD時間 有効なテスト ケース数 トータル 時間 TDD時間 有効なテスト ケース数 トータル 時間 被験者A 無 15 8 67.5 60 11 92.8125 6.5625 -37.5 被験者B 少 83 8 135.5 121 13 140.6875 6.5625 -3.828413284 被験者C 中 26 6 91.625 52 12 78.25 6.5625 14.59754434 被験者D 多 14 4 92.75 23 13 42.6875 6.5625 53.97574124 平均 - 34.5 6.5 96.84375 64 12.25 88.609375 6.5625 6.811218074
15. 検証結果 定性的な結果  メリット  テストの視点を活用することにより，バグ検出に有効な テストケースが追加される  被験者D：intの桁あふれを検出できるintの最大値を使ったケース  テスト設計をすることにより，対象プログラムの設計の 気づきが得られる  被験者D結果：三角形の成立条件の簡略化  被験者コメント：仕様の理解が進み，TDDでやるべき事が明確化  デメリット  テスト設計に慣れていない開発者が，テストの視点を活 用しても，有効なテストケースが得られない  被験者A, B：intの桁あふれを検出できるintの最大値を使った ケースが漏れていた  結果，対象プログラムにもintの桁あふれのバグが残った 15
16. まとめ  テストの視点を活用したTDDアプローチには，従来の TDDと比べ以下の改善効果が認められた  テストケースの網羅度が向上 (平均2.06倍)  TDDと単体テスト工程のトータル工数が減少  平均6.81%減少．テスト設計経験者平均21.6%減少  テストケース・製品コードの品質が向上  残留バグ検出あり  同アプローチには，従来のTDDと比べ以下の課題が認め られた  以下の原因によりTDDと単体テスト工程のトータル工数が上昇 （被験者の2/4）  テスト設計に慣れておらず，テスト設計に時間がかかった  テスト設計を作りこみすぎた 16
17. 今後の展望  テストの視点を活用したTDDアプローチについて， 以下の検討を行う  生産性に影響を与えているテスト設計の習熟度について， モデルやレベルを明らかにする  生産性を最適化するテスト設計の作りこみ基準を明らか にする  アプローチ導入によるテストコードの構造的な品質向上 について評価する 17