2011/10/30 NDS 23rd.内で発表した資料。TDDBC 長岡 0.1 ということで発表。

1. TDDのすゝめ
2011/10/30
NDS 23rd.@まちなかキャンパス長岡
高野 将（TAKANO Sho）

2. TDDのすゝめ
＝
TDDBC 長岡 0.1
2011/10/30
NDS 23rd.@まちなかキャンパス長岡
高野 将（TAKANO Sho）

3. TDDBCとは？
”TDD Boot Camp(TDDBC) とは、テスト
駆動開発(Test Driven Development)に
ついて、座学だけでなく、実習形式で
手を動かして体得することを目的とす
るイベントです。”
TDDBC Wiki より
今回はセッションだけなので、 0.1

4. まず

5. TDDの素晴らしさを気付かせてくれた、
TDDの伝道師 和田 卓人氏 に感謝
http://twitter.com/#!/t_wada

6. 自己
紹介

7. 自己紹介
• 氏名：高野 将（TAKANO Sho）
• ハンドル：まさる
• お仕事：プログラマー兼業主夫
• Blog：まさるblog
http://blogs.wankuma.com/masaru/
• twitter：@masaru_b_cl
• facebook：TAKANO.Sho
• はてなID：masaru_b_cl

8. 著書
かんたん ASP.NET
http://gihyo.jp/book/2010/978-4-7741-4306-4

9. Web掲載記事
.NET開発を始めるVB6プログラマーが知るべき9のこと
http://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_01/greatblogentry_01_01.html

10. 詳しくは・・・
まさるblogで検索してください
<(_ _)>

11. TDDの
すゝめ

12. TDDとは？

13. TDDとは？
“プログラム開発手法の一種で、プログラムに
必要な各機能について、最初にテストを書き（こ
れをテストファーストと言う）、そのテストが動作
する必要最低限な実装をとりあえず行った後、
コードを洗練させる、という短い工程を繰り返す
スタイルである。”
http://ja.wikipedia.org/wiki/テスト駆動開発 より

14. よくわからん
＼（＾ｏ＾）／

15. そんな
あなたに

16. TDDの
すゝめ

17. 改めて、

18. TDDとは？

19. 安心

20. TDDとは？

21. 着実に一歩ずつ

22. TDDとは？

23. テスト
手法
ではなく
開発
手法

24. TDDとは？

25. 才能
ではなく
スキル

26. TDDの進め方

27. ３つのステップ
• Red：失敗するテストを書く
• Green：テストを通すようにコードを書く
• Refactoring：テストが通る状態を維持し
ながら、コードを整理する
これら３つのステップを
「小さく」「すばやく」
繰り返し行う

28. ステップ１：Red
• 要件を実現するために必要な処理について
「失敗する」テストを書く
– コンパイルエラーも失敗に含める
• 十分に「小さい」粒度でテストを書く
– 大きな問題は小さく分解し、各個撃破していく

29. ステップ２：Green
• テストが成功する「最短」のコードを書く
• 「すばやく」テストを通すためには定数を返す
こともいとわない
✓

30. ステップ３：Refactoring
• テストが通る状態を維持したままコードを洗練
させる
– 挙動を変えずに構造を変える
• 必要があればテストコードも整理する

31. 繰り返し
• 三角測量
1つ目のテストと合わせて、より仕様を絞り込
むテストを書く

32. 3つのステップの
繰り返し

33. 3つのステップの繰り返し

34. 3つのステップの繰り返し
着実な道をいく

35. 3つのステップの繰り返し
着実な道をいく
黄金の回転

36. 冒頭の話に戻ると・・・

37. 安心
• それまでに書いた全てのコードに対するテス
トが存在する
→ コードを変更した際、どこかが壊れたら
すぐにわかる
常にテストに守られているという
「安心」
につながる

38. 着実に一歩ずつ
• 小さく、すばやく黄金のサイクルを回す
→ 小さな目標を少しずつ実現
行き先を定め、一歩進み、足元を固める
つまり
「着実に一歩ずつ」
進める

39. テスト手法ではなく開発手法
• テストで仕様を表現
→ 仕様を満たす最適な設計を導く
主眼は「テスト」ではなく
テストを起点に進める
「開発」
にある

40. 才能ではなくスキル
• TDDの進め方は３つのステップの繰り返し
→ やることは決まっているので誰でもできる
才能ではなく、
努力によりTDDの
「スキル」
を身に付ける

41. ３つのステップ以外には

42. 自分が最初のユーザー
• 使いやすいか？
• 名前がおかしくないか？
• 納得できるか？
• 人に見られても恥ずかしくないか？
• etc...
客観的な視点でコードを見直す

43. TDD三原則 by Uncle Bob
• 失敗するユニットテストを成功させるためにしか、
プロダクトコードを書いてはならない。
• 失敗させるためにしか、 ユニットテストを書いて
はならない。 コンパイルエラーは失敗に数える。
• ユニットテストを1つだけ成功させる以上に、 プロ
ダクトコードを書いてはならない。
Uncle Bob（Robert C. Martin）
http://www.butunclebob.com/ArticleS.UncleBob.Th
eThreeRulesOfTdd

44. TDD三原則とは
• TDD養成ギプス
• 原則を守ることで、自動的にTDDに
ただし、あくまで
「原則」
であることを忘れずに

45. TDDの
目的

46. 一言でいえば・・・

47. 健康を保つ

48. 健康を保つ
• 常にGreenを維持
→ 「開発者が認識している」要件を
満たすことが、常に保障される
• テスト可能なコード
→ 他への依存度が低い、つまりは疎結合な
コードになるため、変更に強い
• 小さい粒度でテスト
→ 必要最低限のコードしかないため、
理解しやすい
• 全てのコードに対するテストの存在
→ なにかの拍子に壊しても、すぐにわかる

49. そして・・・

50. コードが健康であれば、
開発者の健康も保たれる

51. さらに・・・

52. 個々の開発者が健康であれば
チームの健康も期待できる

53. TDDを実践してみて

54. 最初はとにかく写経
• まずは「テスト駆動開発入門」を写経すること
から始めた
テスト駆動開発入門
（ケント・ベック著、
ピアソンエデュケーション刊）
http://www.amazon.co.jp/dp/4894717115

55. 次は、どういう観点で
テストを書くかを学んだ
• 「レガシーコード改善ガイド」でテストの書き方
の具体例を学んだ
レガシーコード改善ガイド
（マイケル・C・フェザーズ著、翔泳社刊）
http://www.amazon.co.jp/dp/4798116831/

56. 実装コストは多少増加する
• プロダクトコード以外にテストコードも書くため、
非TDDに比べると実装に時間がかかるように
なった
• ただし、最近は慣れてきたこともあり、1.2～
1.5倍程度で済んでいる印象
• そもそも、非TDDの実装完了って本当に完
了？というのもあるので、本当はそこまで差
がないかもしれない

57. 修正コストは減少する
• 実装中に積み上げたテストが存在するため、
修正が他に影響したらすぐにわかる
• その時点で最もシンプルな設計で実装されて
いるため、仕様変更が他の箇所へ影響を及
ぼしにくい

58. 実装時のテンポがよくなる
• アプリケーションを動作させるため、「ビルド」
や「デプロイ（配置）」が必要だが、それに非
常に時間がかかるケースがある
• TDDでは「ビルド」や「デプロイ（配置）」の待ち
時間がなくなるため、テンポよく実装を進めら
れるようになった

59. 機能単位の「単体テスト」は必要
• TDDで作成するテストは、最小単位の「Unit
Test」
• 機能単位の「単体テスト」は相変わらず必要
– 一つの「機能」はいくつもの「処理」の相互作用で
成り立っているため
詳細設計 単体テスト
• ただし、非TDDに比べれば、「単体テスト」で検
出されるバグが非常に少ない
– 結果として品質が向上する

60. 一つ一つの構成単位が小さくなる
• 小さくテストを作成し、実装するということから、
自然とクラス構造やメソッドなど、プログラム
の構成単位がシンプルに小さくなる
– コード変更の影響が局所化される

61. Demo

62. Demo
“「Googleがらみのネタで！」Returns”
というテーマにちなみ、
Google発の新プログラミング言語
でTDDのデモを行います

63. Demo
FizzBuzz
最初のプレイヤーは「1」と数字を発言する。次
のプレイヤーは直前のプレイヤーの次の数字
を発言していく。ただし、3で割り切れる場合は
「Fizz」、5で割り切れる場合は 「Buzz」、両者で
割り切れる場合は 「Fizz Buzz」 を数の代わりに
発言しなければならない。
http://ja.wikipedia.org/wiki/Fizz_Buzz

64. Demo
もしもの時のために、事前に実施したものも用
意しています。
• TDD for FizzBuzz in Dart – Youtube
http://www.youtube.com/watch?v=-f6bj-Z59h0
• 実際のコード
http://try-dart-lang.appspot.com/s/VxIc
– 使用したTestRunner
http://www.github.com/masaru-b-cl/DartUnit/

65. まとめ

66. 安心

67. 着実に一歩ずつ

68. テスト
手法
ではなく
開発
手法

69. 才能
ではなく
スキル

70. ３つのステップ
• Red：失敗するテストを書く
• Green：テストを通すようにコードを書く
• Refactoring：テストが通る状態を維持し
ながら、コードを整理する
これら３つのステップを
「小さく」「すばやく」
繰り返し行う

71. 3つのステップの繰り返し
着実な道をいく
黄金の回転

72. 健康を保つ

73. 最後に・・・

74. 次は TDDBC 長岡 0.5
予定している内容
• 今回の内容をざっと紹介
• もうちょっと踏み込んだ実践方法の説明
• ライブペアプログラミングしたい

75. というわけで

76. 私とペアプロ
やらないか？

77. やってもいいよーって方は
どんな方法でもいいので
連絡お願いします
<(_ _)>
こわくないよーーーっ！

78. おしまい
明日から早速TDDを実践してみよう！

79. 参考資料、URL
• テスト駆動開発入門
（ケント・ベック著、ピアソンエデュケーション刊）
http://www.amazon.co.jp/dp/4894717115

80. 参考資料、URL
• レガシーコード改善ガイド
（マイケル・C・フェザーズ著、翔泳社刊）
http://www.amazon.co.jp/dp/4798116831/

81. 参考資料、URL
• TDDBC
http://devtesting.jp/tddbc/
• TDD Boot Camp を開催させていただきました - t-
wadaの日記
http://d.hatena.ne.jp/t-wada/20091219/p1
• テスト駆動開発チートシート - やさしいデスマー
チ
http://d.hatena.ne.jp/shuji_w6e/20110429/1304
079615
• TDD とは? - TDD.NET
http://www.tdd-net.jp/whats-tdd.html

82. 参考資料、URL
• TDDワークショップを開催しました - VOYAGE
GROUP エンジニアブログ
http://tech.ecnavi.co.jp/archives/5052434.html