JaSST北海道2012での発表資料

1. テスト駆動開発の導入
ーペアプログラミングによる学習効果ー
2012.10.26 JaSST 北海道
渡辺修司 (@shuji_w6e)
1

2. 自己紹介

3. 渡辺 修司
Javaプログラマ
株式会社エスプラニング所属
ウェブアプリやデスクトップアプリの開発
テスト駆動開発、ユースケース駆動開発
アジャイル開発
最近の趣味はロードバイクとフットサル

4. @shuji_w6e
札幌 Javaコミュニティ
TDD Boot Camp
やさしいデスマーチ（Blog）
執筆活動
WEB DB Press vol.69
JUnit実践入門（Soon!）

5. テスト駆動開発

6. テスト駆動開発とは？
テストコードをプロダクションコードより先
に記述するテストファーストを実践し、
インクリメンタルにソフトウェアを開発する
開発手法
（TDD: Test Driven Development）

7. テスト駆動開発のサイクル
1.設計する
5.リファクタリング
Heuristics
2.テストを書く
4.テストを成功させる
3.コードを書く

8. テスト駆動開発の目的
明確で検証可能な仕様
テスタビリティの高い設計
常にリファクタリング可能
素早いフィードバック

9. ペアプログラミング

10. ペアプログラミングとは？
ペアで１つの作業を行うプラクティス
コードを書くドライバーと、ドライバーのサ
ポートをするナビゲーター
定期的な役割の交代

11. ペアプログラミングの効果
すべてのコードを2人以上が理解している状態
曖昧な状態でコードが書かれない
ツールの使い方やコードの書き方を学べる

12. 問題
http://www.flickr.com/photos/panoptikon/403903803/

13. 典型的なプロジェクトの流れ
(1) 遅れる実装
(2) とりあえずシステムテスト
(3) デバッグ地獄
(4) 後からユニットテスト
(5) 追加開発でリグレッションの発生

14. ぐだぐだになる原因
仕様が複雑でなかなか決まらない
納期のプレッシャー
ユニットテストの工数がない

15. ぐだぐだになる本当の原因
完成の基準が実装者によって異なる
理解不足のままで実装している
変更に対して脆い
スキル不足
担当機能以外に興味が無い
結合すると動かない

16. 事例
http://www.flickr.com/photos/kieon/4313604468/

17. プロジェクトの概要
Java のデスクトップアプリケーション
解析エンジン ＋ GUI（Swing）
5­6名で3ヶ月程度の規模
ミッションクリティカルなシステムのデータ
を解析するツール

18. 導入前
カオスなコード
GUIとビジネスロジックが相互依存
シングルトンパターンの乱用
価値のないテストコード
privateメソッドのテスト
少しの変更で通らなくなるテスト

19. 開発手法の改善
Tracによるissue管理
外部設計にユースケースを導入
自動化（SVN + Maven + JenkinsCI）
ペアプログラミング
テストファースト（テスト駆動開発）
リファクタリング

20. ペアプログラミングの運用
初心者同士ではペアを作らない
２週間を目安にペアを変更
担当個所が偏らないように作業を配分

21. テストファーストの導入
必須とはしない
書ける個所はテストを先に書いてみる
「どうテストするか？」を意識する
イメージが沸かない場合は軽く実装する

22. 開発の流れ
(1) ナビゲータに実装することを説明する
(2) ナビゲータからの質問に答える
(3) 合意したならば、実装を進める
(4) 適宜ツッコミを受ける
(5) 一区切りついたならば役割をチェンジする

23. 効果

24. 作業時間
実装完了時間はほぼ２倍
デバッグ時間は半減
システムテスト後の修正時間は半減
トータルで２­３割増えた程度
※慣れてくれば同程度の時間になる可能性

25. 品質
不具合の質が変化
システムテスト時の不注意的な欠陥が激減
プロジェクト中盤でも安定して動作
欠陥
開発期間

26. <CONFIDENCE>
CONFIDENCE

27. 教育的効果
ツールの使い方
コーディングの技報
他人の「考え方」を知ること
多くの事を学べるが、プログラミングを作業
と考えていると効果は薄い

28. 考察

29. テスト駆動開発とペアプロの効果
効果的なユニットテスト
ユニットテストの強制
考えたことを相手に伝えるプロセス
プロジェクトナレッジの共有
プログラマのスキルアップ

30. 効果的なユニットテスト
CIの導入による素早いフィードバック
プロジェクト終盤での「 褄合わせ」の減少
「無駄なユニットテスト」の減少
privateメソッドのテスト
インターフェイスを意識したテスト

31. ユニットテストの強制
面倒なテストを先に書く
後から書くのはもっと面倒
「動くことを確認するテスト」から
「動かすためのテスト」へ

32. 考えたことを相手に伝えるプロセス
バグのあるコードは「不安なコード」
自信が無いのでコメントで誤魔化す
コードに落とす前に言語化して伝える
考えが曖昧なままで書かれたコードが減少
コピペするにも考える
会話が増える

33. プロジェクトナレッジの共有
「この機能はXXさんが担当したから解らな
い」がほとんどなくなる
知見をチームに伝搬させる
担当ではない機能にも興味を持たせる

34. プログラマのスキルアップ
コーディング上のテクニック
ツールの使い方
デザインパターン
リファクタリング
問題に対する「考え方」

35. 課題
http://www.flickr.com/photos/togemaru/2882075323/

36. 基礎体力は必要
プログラミングスキル
リファクタリング
設計パターン
テストスキル

37. 教育的コスト
初心者にとって学べることは多い
プロジェクトのリソースと教育コスト
当然のように教育コストを払ってくれない
余裕のないプロジェクトでは難しい
一時的なメンバーでは効果が薄い

38. 実績と経験者
経験者がいないと難しい
ワークショップなどで「素振り」が必要
初心者は経験者と組むことで楽
経験者は思った以上に疲れる

39. ワークショップのススメ
半日から数日のワークショップ
テストファーストとペアプロに慣れる
小さなアプリを作成できると良い
必ずリファクタリングまで回すこと

40. まとめ

41. テスト駆動開発（ テストファースト）
先に振る舞いを考えることの効果
テスタビリティの高いシンプルな設計
動作するきれいなコード/リファクタリング
ペアプログラミング
スキルの伝搬
プロジェクトナレッジの共有
コミュニケーション

42. 質疑応答