1. テスト駆動開発者は
3周目に死ぬのか
和田 卓人 (a.k.a id:t-wada)
Jul, 7th 2009 @ object club

2. 自己
紹介

3. 自己紹介
名前: 和田 卓人 (わだ たくと)
ブログ: http://d.hatena.ne.jp/t-wada
メール: takuto.wada@towersquest.jp
Twitter: http://twitter.com/t_wada
タワーズ･クエスト株式会社
取締役社長

4. これまで書いたもの
WEB + DB PRESS
vol.35 「実演! テスト駆動開発」
vol.37 「実演! リファクタリング」
vol.42 「REST特集」
vol.49 「DRY特集」
LifeHacks PRESS
オープンソースマガジン(リレーコラム)
他いろいろ

5. gihyo.jpの連載
『［動画で解説］和田卓人の テスト駆動開発 講座』
http://gihyo.jp/dev/serial/01/tdd/
全20回すべて動画付き解説
ニコニコ動画でも見れます
WEB+DB過去記事の特設サイトと動画も

6. デベロッパーテスティング・ライブ - 自信を持ってコードを書くための
心・技・体 -
【徹底討論】テストなんていらない？！ -テストを、どこまでやる
べきか？
パネルディスカッション：テストを行うこと、テストを続けること
デブサミ

8. よろしく
おねがい
します

9. 今日喋ること
•ピラミッドを組み上げる
•ピラミッドの中に入る(戻る)
•黄金の回転について

10. “TDD done strictly from the
YAGNI principle leads to an
architectural meltdown
around iteration three.”
TDD を YAGNI 原則に則って厳格に行うな
らば、3イテレーション目でアーキテクチャ
が破綻するであろう

11. “TDD done strictly from the
YAGNI principle leads to an
architectural meltdown
around iteration three.”
TDD を YAGNI 原則に則って厳格に行うな
らば、3イテレーション目でアーキテクチャ
が破綻するであろう
Jim CoplienBob Martin

12. 第一部
ピラミッド
を組み上げる

14. Emergent Design
Test Driven
Development
Refactoring
Pattern Driven
Development
Code Qualities
Principles Practices PathologiesWisdom
Unit Testing Patterns

15. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

17. Emergent Design is the process of evolving systems in
response to changing requirements, better
understanding of existing requirements, and in
response to new opportunities that arise from new
technology, better ideas, and a changing world.
創発的設計とは仕様の変更や、既存の仕様のより
深い理解、また新たな技術、よりよいアイデア、
環境の変化などに適応してシステムを進化させる
プロセスである
創発的設計とは

18. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

19. Code Quality
解析容易性
変更容易性
安定性
テスト容易性

21. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

22. Pathologies

23. 名前を付けるのが難しい
長いテストコード
長いプロダクトコード/メソッド
(例)凝集度不足

24. •パターンへ昇華
•Anti-Patterns
•リファクタリングの兆し
•Code Smells
Pathologies

25. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

26. Wisdom
先人の知恵
巨人の肩
c2.com
FLOSS

27. 藤野さん
平鍋さん
天野さん
懸田さん
矢崎さん
小井土さん
福井さん
井上樹さん
河合さん
佃さん
中谷さん
平澤さん
梅澤さん
友野さん
長瀬さん
金澤さん
浅海さん
原田洋子さん
萩本さん
伊藤さん

28. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

29. Principles

30. Single Responsibility
Open-Closed
Liscov Substitution
Interface Segregation
Dependency Inversion
SOLID Principle

31. Don t Repeat Yourself
Law of Demeter
Principles

32. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

33. Practices
スタイル
名前
道具

34. 三本柱
©Artek ( http://www.artek.fi/ )

35. バージョン管理
テスティング
自動化

36. バージョン管理

38. テスティング

39. 自動化
自働化
XFD
詳しくは小井土さんセッションで

41. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

42. バージョン管理
テスティング
自動化

43. テストの分類
Developer
Testing
開発者
開発促進
Customer
Testing
顧客
(のロール)
進捗管理
QA
Testing
品質保証
担当者
(のロール)
品質保証
「テスト」

44. Developer Testingとは
•プログラマの
•プログラマによる
•プログラマのための
•プログラムとしてのテストを書きながら
•開発を行っていく手法

45. xUnit

46. バグ発見とコスト

47. •即座にフィードバックを得るため
•書いたコードに自信を持つため
•これから書くコードに自信を持つため
Developer Testing に
ソフトウェア工学的なメリットはいろいろある
けれど、最大の理由は工学的なものではない。
最大の理由は心理的なもの

48. どこをテスト
すべき？

50. デバッガじゃ
だめなの?

52. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

54. リファクタリング(名)
外部から見たときの振る舞いを
保ちつつ、理解や修正が簡単に
なるように、ソフトウェアの内
部構造を変更させること

55. リファクタリング(動)
一連のリファクタリングを行っ
て、外部から見た振る舞いの変
更なしに、ソフトウェアを再構
築すること

56. 理解や修正のために
•コードを理解しやすく
•コードを修正しやすく
•コードをシンプルにすること
が、シンプル設計への道

57. リファクタリング
•ボトムアップ設計の核
•全ての中でリファクタリングだ
けが、物事を後から改善できる
•「向き」が大事

58. リファクタリ
ングに終わり
はあるのか?

59. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

60. Patterns
語彙
形式
共有

61. (例)Facade
Context
外部要因に依存する複雑なサブシステ
ムがある
Force
複雑化する内部実装に依存しないよう
にしたい
Solution
Facade Patternを導入し、シンプルな
interfaceの背後に複雑な内部を隠 する

64. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

66. TDDとは
1. テストを書き
2. そのテストを実行して失敗させ(Red)
3. 目的のコードを書き
4. １で書いたテストを成功させ(Green)
5. テストが通るままでリファクタリング
を行う(Refactor)
6. １∼５を繰り返す

67. • a test driven developer does not write a line of production
code until he has written a failing unit test, and no production
code can be written until there is a failing unit test
• you do not write more of a unit test than is sufficient to fail,
and “not compiling” is failing. So you cannot write very much
of the unit test before you must write production code;
• you cannot write more production code than is sufficient to
pass the currently failing test. So you cannot write a little bit of
a unit test and then run off and write a whole bunch of
production code.
Discipline

68. TDDの
こころ

69. 一つずつ
少しずつ

70. ひとりずつ
対処する。
複数を相手
にしない。

71. 動作する、きれいなコードへ
きれい
汚い
(すぐには)動かない 動作する
二つの道がある

72. すばやく
まわす

73. きれい
汚い
(すぐには)動かない 動作する
Red
Green
Refactoring
TDDと黄金の回転

74. 自分が最初の
ユーザ

75. 不安を
テストに

76. ボールは
ひとつ

77. TDDは
テスト技法では
ない

78. TDDは
品質を
保証しない

79. TDDは
品質を
向上する

80. TDDは
設計技法です

81. テストは目的
ではなく手段

82. TDDの
真の目的

83. 健康

84. 変化に対応す
るのは健康体
のコード

85. 変化に対応す
るのは健康体
のチーム

86. 不安の克服
健康の維持

87. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

88. “TDD done strictly from the
YAGNI principle leads to an
architectural meltdown
around iteration three.”
TDD を YAGNI 原則に則って厳格に行うな
らば、3イテレーション目でアーキテクチャ
が破綻するであろう
Jim CoplienBob Martin

89. 誤解を解く
•全てのコードをゼロから書くわ
けではない
•BDUF - ENUF - YAGNI
•スタートでもゴールでもある

90. 見えているのに?
•「目配せ」と「快晴」
•Simple と Naive
•経験と叡知
•内なる声を聴く

92. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

93. 私たちが
気付くのは
いつ?

94. 何が変わる?
•外が変わる
•市場
•技術
•内が変わる
•学び
•よりよいア
イデア

95. フィードバック
学びを
否定しない

96. 計画する
計画し続ける

97. 設計する
設計し続ける

98. Emergent Design is the process of evolving systems in
response to changing requirements, better
understanding of existing requirements, and in
response to new opportunities that arise from new
technology, better ideas, and a changing world.
創発的設計とは仕様の変更や、既存の仕様のより
深い理解、また新たな技術、よりよいアイデア、
環境の変化などに適応してシステムを進化させる
プロセスである
創発的設計とは

99. 第二部
ピラミッド
に入る/戻る

100. Emergent Design
Test Driven
Development
Refactoring
Pattern Driven
Development
Code Qualities
Principles Practices PathologiesWisdom
Unit Testing Patterns
Reality Bites
現実は厳しい

101. Reality bites
•スタート地点の違い
•テストが無い
•データが既に入っている
•量、記憶、変化、プレッシャー

102. 既にテストの
ないコードが
沢山ある

104. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
パターン
プラクティス 病理学

106. Edit and Pray

107. Cover and Modify

108. 既にデータの
入ったデータ
ベースがある

111. データと戦う
•データベースもリファクタリン
グする
•本気度が高い
•長いリファクタリング期間

112. テストの
Paradox

113. テストが増えると
リファクタリング
が面倒くさくなる

114. Fragile
Tests

115. 実装に
依存しすぎ

116. コード変えたら
テストが真っ赤

117. Slow Tests

118. テストが
遅すぎる

119. なぜか
テストが
足枷に

121. テストが
リファクタリング
支えるのでは
なかったのか？

124. テストの量と戦う
•減らす
•速くする
•関連を明らかにする

125. テストの価値の軸
•速さ
•実装との距離
•コードの重複率
•ドキュメントとしての価値

126. 自分の記憶力と戦う
•意図を伝えるコード
•意図を伝える名前
•意図を伝える構造
•コメント(Why / Why not)

127. テストの
資産価値

128. 攻め続ける
ためのテスト

129. なるべく
実装に
依存しない

130. リファクタリング
を支えるテストが
良いテスト

131. TDDと黄金の回転
きれい
汚い
(すぐには)動かない 動作する
Red
Green
Refactoring

132. テストの
資産運用

133. 役割と
寿命

134. 1.価値の低いテス
トの価値を高める

135. テストの
リファクタリング

137. 2.価値の低いテス
トを捨て、高いテ
ストを残す

138. テストを
減らす

139. そこで
カバレッジ

140. Aのカバレッジが
Bのカバレッジを
内包するとき、
テストB は消せる

141. まとめ

142. 創発的設計
テスト駆動開発
リファクタリング
パターン駆動開発
コードの質
原則叡知
ユニットテスト パターン
プラクティス 病理学

143. きれい
汚い
(すぐには)動かない 動作する
Red
Green
Refactoring
TDDと黄金の回転

146. おわりに

147. TDDはスキルです
• テストやTDDはスキルです。つまり…
• 才能ではなく、習得可能です
• 量は質に転化します
• 写経!!

148. ご清聴
ありがとう
ございました