at Open Seminar Hiroshima 2014 (#osh2014) 2014.02.01 (Sat) http://osh-2014.github.io/

1. TDDの
こころ
和田 卓人 (a.k.a id:t-wada or @t_wada)
Feb 1, 2014 @ OSH2014

2. 和田 卓人
id: t-wada
@t_wada
github: twada

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

6. こんな風景

7. 荒みきったコード

8. 疲弊しきった現場

9. 爆弾処理のようなリリース

10. なぜこうなっ
てしまうのか?

11. http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

12. 左サイドだけでは点は取れない

13. 誰がシステム
を作り続ける
のか

14. TDD
とは？

16. 最後に残った４つの章では、
私が「問答無用で実践すべ
き」だと考えているアジャイ
ルなソフトウェアエンジニア
リングのプラクティスを紹介
していきたい。具体的には次
の４つだ。

17. アジャイルなプログラミング
•
第13章 リファクタリング
•
第14章 テスト駆動開発
•
第15章 継続的インテグレー
•
第12章 ユニットテスト
ション

19. 絶版!

20. 「動作するきれいなコード」、ロン・ジェフ
リーズのこの簡潔な言葉は、TDD(テスト駆
動開発)の目標である。動作するきれいなコー
ドは、あらゆる理由で価値がある。
─ Kent Beck

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

22. TDDのサイクル
1. 次の目標を考える
2. その目標を示すテストを書く
3. そのテストを実行して失敗させる(Red)
4. 目的のコードを書く
5. 2で書いたテストを成功させる(Green)
6. テストが通るままでリファクタリングを行
う(Refactor)
7. １∼6を繰り返す

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

25. 絶版!

27. TDDの
こころ

28. 一つずつ
少しずつ
段を
小さく

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

30. すばやく
まわす

31. 自分が最初の
ユーザ

32. 不安を
テストに

33. 命綱を編む

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

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

36. TDDの
真の目的

37. 健康

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

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

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

41. デモ

42. FizzBuzz問題
Write a program that prints the numbers from 1 to 100. But for
multiples of three print “Fizz” instead of the number and for the
multiples of five print “Buzz”. For numbers which are multiples of
both three and five print “FizzBuzz”.
1から100までの数をプリントするプログラムを書け。ただし3
の倍数のときは数の代わりに｢Fizz｣と、5の倍数のときは
｢Buzz｣とプリントし、3と5両方の倍数の場合には｢FizzBuzz｣と
プリントすること。
http://tickletux.wordpress.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/
http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

43. 事例

44. TDD導入効果(MS, IBM)
IBM Driver MS
Windows
MS MSN
MS Visual
Studio
ソースコードサイズ (KLOC)
41.0
6.0
26.0
155.2
28.5
4.0
23.2
60.3
0.61
0.38
0.24
0.09
15∼20%
25∼35%
15%
20∼25%
テストコードサイズ (KLOC)
TDDを採用していない類似プロ
ジェクトでの欠陥密度を１とし
たときの欠陥密度
TDD採用により増加したコード
実装時間(管理者の見積による)
N. Nagappan, M. E. Maximilien, T. Bhat and L. Williams: Realizing quality improvement through test driven development: results and
experiences of four industrial teams, Journal of Empirical Software Engineering, vol. 13, pp. 289-302 (2008)
44
© Towersquest, Inc. 2010. all rights reserved.

45. TDD導入効果(エリクソン他)
• TDDを実施した場合に報告されている知見
‣
機能テストでの不具合検出数が18%削減された
‣
コーディング(実装)の時間が16％増えた
‣
テストのカバレッジが大きくなった
• 被験者を対象としたアンケート
‣
96%の被験者がデバッグの工数を減らすと感じた
‣
88%の被験者が要求が洗練されると感じた
‣
92%の被験者がコードの品質を上げると感じた
‣
50%の被験者が開発工数を減らすと感じた
Boby George, a and Laurie Williams: A structured experiment of test-driven development, Journal of Information and Software Technology Vol. 46, No. 5, p. 337-342(2004)
45
© Towersquest, Inc. 2010. all rights reserved.

46. 応用

47. テストの無いコードが
既にたくさんある

49. JUnit を
マスターしたい

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

53. 絶版!

54. Fragile
Tests
テストが
脆い

55. Slow Tests
テストが遅い

57. どこまでテストすればよいのか

59. 現実のシステムはもっと複雑だ

61. 画面のテストはどうすれば?

63. 組み込みシステムはどうすれば?

66. おわりに

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

68. 本をたどる

69. 絶版!
絶版!
絶版!
絶版!
絶版!
絶版!
絶版!

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

71. TDDはスキルです
• ひとりから始められる
• テストやTDDはスキルです。つまり…
• 才能ではなく、習得可能です
• 量は質に転化します
• 写経!!

72. テストはプロの嗜み
ご清聴ありがとうございました