2014/05/18 TDDBootCamp in Nagoya でkyon_mmが基調講演に使用したスライドです。org-mode -> reveal.js -> pdfで変換したのでアニメーションは切られています。BDDようそ

1. いつでも聞ける
TDD入門
@KYON-MM
- TDDBC IN NAGOYA #2 - 2014/05/18
0

2. TABLE OF CONTENTS
TDDBCへようこそ
TDDの基本
プロフェッショナルな話
TDDによる良い開発
BDDという存在
エンピリカルな話
TDDと共に学ぶ
最後に

3. 1 TDDBCへようこそ
本日はTDDBootCampへ参加してくださってありがとう！
まずはTDDBootCampがどんなものかを説明します！

4. 1.1 TDDBCで得られるもの
TDDBootCamp(TDDBC)はTDD(テスト駆動開発)の考え方を聞
いて、実際にやってみるイベントです。 TDDBCを終える
と、なんらかの形でTDDを自ら学習、試行錯誤、実践ができ
るだけの基礎体力がつきます。

5. 1.2 TDDBCの方向
TDDって言葉を知らなくてもTDDを試行錯誤できること
TDDを学ぶ知の高速道路を提供すること
注意：TDDBCで提供できることは基本的なことや一例でしか
ありません。

6. 1.3 TDDBCのプログラム
熟練者による概念や基本の講演
参加者が実際にTDDでプログラミング
TAによるTDDへのサポート
参加者からの質問にTAが答える

7. 1.4 TDDBCをまとめると
TDDBCはTDDを身に付けるための基礎体力をつけられます。
日本各地で有志によって開催されているとてもなごやかなイ
ベントです。
今日はぜひ楽しんでいってください。

8. 2 TDDの基本

9. 2.1 TDDの言葉
プロダクトコード：これからつくるソフトウェアのコード
のこと。
テストコード：ソフトウェアを実際に動作させて検証する
コードのこと。
RED : テストコードが失敗している状態のこと。
GREEN: テストコードが成功している状態のこと。
REFACTOR(リファクタリングする) : コードを綺麗にするこ
と。

10. 2.2 TDDの原則や手順
基本は下の手順を繰り返す。
要求されていることを分解して再構築する。
分解した要求をテストコードで表現する。
テストコードを実行してREDになることを確認する。
テストが成功するようにプロダクトを実装する。
テストコードを実行してGREENになることを確認する。
テストコードが成功しているなら、リファクタリングす
る。

11. 2.2.1 TDDの状態遷移

12. 2.2.2 より大きなTDDの状態遷移

13. 2.2.3 KENT BECK SAYS…
自動テストが失敗した場合だけ、新しいコードを書く。
重複を取り除く。
2つの規則はプログラミングのタスクにおける順番を意味
する。
レッド：動作しないテストを少しだけ作成する。おそらく
最初はコンパイルできない
グリーン：テストをすぐに動作させる。そのためには、ど
のようなコードでもよい
リファクタリング：テストを動作させるためだけに作成さ
れた重複を全て取り除く

14. 2.2.4 UNCLE BOB SAYS…
3つの原則を守りながら実装を進める。
失敗するテストができるまでプロダクトを書いてはいけな
い
失敗するテストがある場合にはそれ以上テストを追加して
はいけない
テストを成功させるプロダクトがある場合にはそれ以上プ
ロダクトを追加してはいけない

15. 2.3 TDDは何であって、何ではないか

16. 2.3.1 KENT BECK SAYS…
「TDDとは分析技法および設計技法であり、実際には開発全
てのアクティビティを構造化するための技法である。」

17. 2.3.2 UNCLE BOB SAYS…
「TDDは魔法や宗教ではない。3原則に従ってもひどいコー
ドを書くことはできる。TDDをすることで害が大きい場合に
おいてでさえもTDDをするのはプロではない。」

18. 2.3.3 TDDの状態遷移

19. 2.3.4 TDDとは
TDDとはソフトウェア開発の優れたフレームワークであ
る。
TDDとはこれから作るべきものをまずはテストコードとし
て書いてみる。
TDDを宗教にしてしまうのはいつもユーザーである。

20. 2.4 TDDの大切なこと
自分がすぐに出来そうなものまで要求を分解、再構築して
サイクルを回す
分解前の要求を満たすことも忘れずに
プロダクトコードを書く前に設計をテストコードとして書
いて、プロダクトコードを書く。
テストが成功したら、失敗するテストコードを書いて、新
しいプロダクトコードを書く。
テストが成功しているときだけリファクタリングする。
短かいサイクルで回せないときは立ち止まる。
作るものの大きさが違えば使う立場も変わってくる。その
立場でテストを表現する。

21. 3 プロフェッショナルな話

22. 3.1 TDDを実践するということ
TDDを実践することは、ほとんどの場合において「プログ
ラマーとして当然のことである」と考えてよいです。
それはあなたが毎日顔を洗うことと変わりません。
ただ、どのような洗顔がいいのかが個々人で異なるよう
に、あなたのスキルセット、そしてプロジェクトによって
最適なものは違うのです。
最適なものを探す上で基本に忠実であること、そして幅広
い知識はとても大切です。

23. 3.2 TDDがもたらすこと
「曖昧で実行できない自然言語だけの意図を煩雑にも確認
していく日々」から「明確で実行できる意図を何度も簡単
に確認していく日々」へ。
「主観的な進捗確認」から「客観的な進捗確認」へ。
「動作に自信のないコード」から「つまらない確認不足の
ないコード」へ。

24. 4 TDDによる良い開発
ここではkyon_mmの経験の中からおそらくは多くのTDD熟練
者から共感してもらえそうな内容を紹介します。

25. 4.1 TDDの状態遷移

26. 4.2 分析、設計
ソフトウェア開発では自分がこれからつくるべきもの達の
関連や詳細を分析し、再構築し、設計します。
TDDではその分析や設計のアウトプットとしてテストコー
ドを使い、実際に実装をしていき、設計と適合しているか
を確かめ、ソフトウェアをイテレーティブに成長させてい
きます。
机上の分析や設計もとても大切ですが、TDDをすすめいく
と、その設計内容が現在のプロダクトとどのように乖離し
ているかがすぐにわかるようになります。
実行可能で生きたドキュメントをつくりながら開発をして
いく手法。それがTDDです。

27. 4.3 確実な成果に結びつける
TDDでは進捗80%というのはありません。例えば次の2点が
ポイントになります。
設計をテストに表現できたか？
どのテストが通っているか？

28. 4.4 機敏に感じとる

29. 4.4.1 なかなかGREENにならないとき
あなたの作業単位は大きすぎる可能性があります。REDに
しているテストを変更前に戻して、もとの要求を再び分
解、再構築してテストにしましょう。
あなたのコードが汚ない可能性があります。REDにしてい
るテストを変更前に戻して、プロダクトコード、テストコ
ードをリファクタリングしましょう。

30. 4.4.2 機敏の尺度
RED -> GREEN-> REFACTORのサイクルでどれくらいの時間
がかかったときに「立ち止まるべきか」の目安。
初級者 : 10分
中級者 : 5分
上級者 : 1分

31. 5 BDDという存在
BDD = Behavior Driven Development

32. 5.1 BDDとは
テストコードに書くのは「対象の振舞いである」とする手
法です。
手順や原則やガイドは基本的に今迄説明したものと変わら
ないです。

33. 5.2 TDDの状態遷移

34. 5.3 TDDとBDDに違いはない
根本的にTDDとBDDは違わず、それまでのTDDの語彙では
伝わりにくかった部分を言い換えたり、テンプレートを与
えることで幾分かハードルを下げるという役割を持ってい
ます。
「TDDツール」や「BDDツール」という表現があります
が、あくまで「BDDをしやすいテスティングフレームワー
ク」というくらいです。

35. 5.4 振舞いとはなにか
振舞いとは「【対象(つくろうとしているもの)】における
『何らかのイベント』にひも付く外部から見える変化」のこ
とです。 イベントは対象によって変わります。
「【関数】に対する『入力』出力」
「【オブジェクト】の『メッセージング』」
「【画面】の『操作／表示』」
「『時間の経過』による変化」

36. 5.5 なぜ振舞いを書くのか
Dan Northは次のような言葉を残しています。
表現力のあるテスト名は失敗したときに役に立つ。
バグを埋め込んでしまった。悪い子だ。解決法：バグを直
す
意図された振る舞いは変わらず関連性があったが、どこか
別の場所に移されていた。解決法：テストを移動し、場合
によっては変更する
振る舞いがもはや正しくない。システムの前提が変わって
しまっている。解決法：テストを削除する
– BDDの導入 -Dan North

37. 5.6 振舞いを書くとは
「どんな対象であるか」「対象が何をするのか」についてよ
り言及できているものが「表現力がある」といえます。
「対象の振る舞いを記述する」ことについてソフトウェアか
ら離れて例を出します。 例えば、あなたが友人や親や配偶者
や子供が普段どのようであるかを説明するときに何と答える
でしょうか？

38. 5.7 振舞いの記述の良い例と悪い例
「歩くことができる」「手を握り返せる」「信号の区別が
付く」「笑う」
「晴れている日に一緒に歩いていると、赤信号で止まった
ときに笑いながら手を強く握り返してくる」
後者が説明的で実例としての振る舞いを表現しているのに
対して、前者はどのような人であるかは想像が難しいので
す。前者は振舞いを書いているとは言い難いでしょう。

39. 6 エンピリカルな話
エンピリカル = (実証的。経験的データに基づいた。)

40. 6.1 MS,IBMなどの事例
TDDを導入したプロジェクトで類似プロジェクトとの比較
IBM
Driver
MS
Windows
MS
MSN
MS
VisualStudio
Product(KLOC) 41.0 6.0 26.0 155.2
Test(KLOC) 28.5 4.0 23.2 60.3
非採用プロジェクトと
の欠陥密度比較
0.61 0.38 0.24 0.09
実装の追加工数 15 -
20%
20 -35% 15% 20 -25%
Realizingqualityimprovementthrough testdriven development:
results and experiences of four industrialteams Nachiappan
Nagappan &E. MichaelMaximilien &Thirumalesh Bhat&Laurie
Williams

41. 6.2 各種レポートのまとめ
複数の論文、レポートで言われているTDDの効果をまとめて
項目別に比較
※項目別にレポートによって対象外あり
よい効果,変化なし 悪い効果
バグ 7 1
外部品質 9 0
カバレッジ 11 0
生産性 9 3
Effects of Test-Driven Development: AComparative Analysis of
EmpiricalStudies Simo Mäkinen and Jürgen Münch

42. 6.3 初級者と熟練者の違い
「テストを先に書くテストファースト」と「テストを後から
書くテストラスト」のどちらを選びたいか等を比較
熟練者 : テストファーストをしたい人は6割以上
初級者 : テストファーストをしたい人は2割未満
An EmpiricalEvaluation of the Impactof Test-Driven
Developmenton Software QualityByCopyright2006 David
ScottJanzen

43. 7 TDDと共に学ぶ

44. 7.1 TDDを学ぶ
(1)
(2)
(3)
テスト駆動開発入門
テスト駆動開発実践入門
Clean Code
Specification ByExample
BDD in Action
@IT連載の「いまさら聞けないTDD/BDD超入門」
@IT連載の「いまさら聞けないTDD/BDD超入門」
@IT連載の「いまさら聞けないTDD/BDD超入門」

45. 7.2 綺麗なコードを学ぶ
Clean Code
Code Complete
リーダブルコード

46. 7.3 既存コードとの接し方を学ぶ
テストがないプロダクトや、保守性の低いプロダクトでTDD
する
リファクタリング
レガシーコード改善ガイド
データベースリファクタリング

47. 7.4 テストを学ぶ
TDDを活かすためにテストコードの保守性やテストプロセス
学ぶ
xUnitTestPatterns
マインドマップではじめるソフトウェアテスト入門
知識ゼロから学ぶソフトウェアテスト 【改訂版】
ソフトウェアテスト実践ワークブック
ソフトウェアテスト技法
実践アジャイルテスト

48. 7.5 アーキテクチャを学ぶ
いきあたりばったりなTDDにならないようにアーキテクチャ
を学ぶ
エンタープライズアプリケーションアーキテクチャパター
ン
エリックエヴァンスのドメイン駆動設計
アナリシスパターン
オブジェクトデザイン

49. 7.6 自動化を学ぶ
TDDによって得られるテストやプロダクトをスムーズにビル
ドしリリースできるようにする
Jenkins
継続的デリバリー
Gradle in Action
Chef実践入門(多分良書)

50. 7.7 バージョン管理を学ぶ
コードの共有、試行錯誤、機能自体の履歴管理、バグ調査、
CIをしやすくする
SCMBootCampへ！
Gitポケットリファレンス
入門Git
入門TortoiseHg+ Mercurial
実用Git

51. 8 最後に
TDDをしなくても要求を満たせるようになることは素晴し
いことです。
ですが、あなたが持っている要求の情報、分析結果、設計
スキル、実装スキルが不足しているとき。
そしてそのソフトウェアを保守する未来の誰かがそれに見
合わないときはおそらくTDDが最良の選択であることは非
常に多いでしょう。
Have aGood Development!