テストの視点を活用した

TDDアプローチの検討と検証

ＴＤＤ研究会 池田 暁

井芹 洋輝 太田 健一郎

はじめに –本報告の要点

TDD(Test Driven Development)について Agile開発を中心に普及しているプログラミング手法

テストファーストでユニットテストを作成し，それをパスする製品コードを追加・変更していく

TDDの課題 TDDでのテストはプログラミングのサポートが目的であり，バグ・仕様未達を網羅的に検出すると保証できない バグ・仕様未達の網羅的な検出が必要ならば，単体テスト工程などで別途ユニットテストを実施する必要がある．TDDでテスト工数の削減ができず，トータル工数が上昇する可能性がある

今回の要点 本研究会では，TDDにテストの視点を導入，バグ・仕様未達の検出に優れたTDDアプローチの検討を行った

今回はその基礎検証の報告を行う

2

ＴＤＤの概要

TDD[1]は下記の3ステップを繰り返してプログラミングを進める開発手法である

1. 失敗するユニットテストを書く（Red）

2. そのテストをパスする小さなコードを書く（Green）

3. ユニットテストがパスする状態を維持しながら，コードの設計を改善する(Refactor)

3

RED

GREEN REFACTOR

[1] ケント・ベック 『テスト駆動開発入門』 長瀬嘉秀監訳，（株）テクノロジックアート訳，ピアソン・エデュケーション，2003年．ISBN 4894717115

ＴＤＤの課題

TDDのテストはプログラミングの効率化が目的．バグ・仕様未達を網羅的に検出できると保証できない

バグ・仕様未達の網羅的な検出が必要ならば，単体テスト工程などで別途ユニットテストを実施する必要がある．TDDでテスト工数の削減ができず，トータル工数が上昇する可能性がある

4

開発工程(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

テストの視点を活用するＴＤＤプロセス

リファクタリング (Refactor[PRODUCT])

テスト設計の洗練 (VERIFY&DEBUG)

RED

GREEN

VERIFY&

DEBUG

REFACTOR

•TEST

•PRODUCT Green

Assertファースト による追加・変更 （RED→GREEN）

テストコードの 設計改善

（REFACTOR[TEST]）

9

改善したＴＤＤプロセスの検証（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

改善したＴＤＤプロセスの検証（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