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