TDD実践講座

テスト駆動開発をハンズオンで学べる！

タイムテーブル

1. TDDのこころ (講義)

2. TDDデモ＆チュートリアル

3. TDD体験セッション

4. 全体コードレビュー

5. TDD応用編 (講義)

6. ふりかえり

すごい講師とTAがつきっきり！

http://event.shoeisha.jp/aa#Professors

和田卓人id: t-wada@t_wadagithub: twada

太田 健一郎

株式会社 SHIFT

Test AutomatorJenkins Selenium Geb JavaScript

テスト自動化

CI

twitter:@oota_ken facebook:oota.kengithub:ootaken

安井 力 / やっとむtwitter:@yattomhttps://www.facebook.com/yattom

プログラマーJava Python Ruby JavaScript

テスト駆動開発

アジャイルコーチワークショップ 現場導入 技術支援

コンサルタントモデリング

16

The Scrum Field Guide (Mitch Lacey)和訳が出ます！

(安井力、近藤寛喜、原田騎郎 訳)

「本書はガイドとして、スクラムの初歩から熟達に向け、現実的な

方法を指導してくれる。…より高度で実践的な、スクラム

フレームワークをあなた自身とあなたのチームで機能させるための

ガイドだ。」(ジム・ハイスミス)

発売日: 2月26日予価: 3,480円マイナビ出版

Amazon.co.jpにて予約受付中！

カンバン仕事術―チームではじめる見える化と改善

(Kanban In Actionの翻訳)

発売日: 3月25日予価: 3,888円

オライリージャパン

Amazon.co.jpにて予約受付中！

ペアプロやコードレビューでお互いに学び合う場

ペアプログラミングとは

"Write all production programs with two people sitting at

one machine. ... Pair programming is a dialog between

two people simultaneously programming (and designing

and testing) and to program better."

(Extreme Programming Explained 2nd)

「プロダクションコードはすべて、2人で1台のマシンに向かって書くこと。…ペアプログラミングとは、プログラミングしながら2人で会話することだ(設計もテストも同時にする)。会話するのは、もっと上手にプログラムするためである。」

ふりかえり

Keep(よかったこと)の例

• TDDがどういうものなのか理解できた※誤った認識を今まで持っていた……

• 今日学習した黄金のサイクルは今後も意識的に続けていこうと思った。

• 気づかないうちにチェックされていた→必要なときに正に指摘を受けた

Try(これからやりたいこと)の例

• 新規のプロジェクトでTDDを導入してみようと思う

• 自宅で復習と理解を深めるためにビールを飲みながら独りTDDをやってみる

• 今日から写経をはじめます

体験しないとわからない

TDDの特徴

• 体験しないとわからない (ペアプロも)

• 練習すれば上達する

• 状況、対象、設計、スキルなどに応じて幅広い様々な手法、アプローチがある

TDD実践講座の特徴

• 体験しないとわからない (ペアプロも)

• 練習すれば上達する

• 状況、対象、設計、スキルなどに応じて幅広い様々な手法、アプローチがある

• 体験できる(ペアプロも)

• 練習を始めるきっかけになる

• 熟練者、経験者に具体的相談ができる

TDDBC(TDD Boot Camp)

• コミュニティによるイベント

• ボランティア講師・ＴＡ• ハイレベル(な人も来てくれる)！

• 土日 半日～1日

• 全国で不定期に開催

• 無料！

• 2/27(土) 東京

https://tddbc.doorkeeper.jp/

よくある質問

TDDはテストですか

TDDはテスト手法か？

• テスト駆動開発 ＝ 開発手法

• TDDはテストの代わりにならない• 部分的に担保できることもある

• TDDで書いたテストも積極的に整理(削除)する

• 「TDDだからテストしないよ！」ちょっとそこに座れ

っていうか実践講座来なさい

TDD導入したいけどコストが増えそう

テスト駆動開発の効果

IBMドライバ

MicrosoftWindows

MicrosoftMSN

MicrosoftVisualStudio

チーム人数 9 6 5-7 7

コード量(KLOC) 41.0 6.0 26.0 155.2

開発規模(人月) 119 24 46 20

欠陥数(TDD未使用に対する)

61% 38% 24% 9%

開発時間の増加(管理者の見積)

15～20％ 25～35％ 15％ 20～25％

Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through test driven development: results and experiences of four industrial teams” 2008http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

保守性への影響

※1 保守期間(260日間)中、変更要求の対応にかかった工数の平均

"The effectiveness of test-driven development: an industrial case study"

(Tomazˇ Dogsˇa • David Baticˇ , Software Qual J (2011))

生産性(行数/工数)

保守性 ※1

(工数/変更件数)

プロジェクトA(非TDD)

2.3 84

プロジェクトB(非TDD)

2.5 80

プロジェクトC(TDD)

1.8 59

TDDの効果の研究をまとめた研究

"Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and JurgenMunch, 2013

• 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究の結論を整理した

• TDDは欠陥の作り込み(introduced defects)を減らし、メンテナンスしやすいコードを産む

• TDDで実装されたコードは、部分的に、サイズが小さく、複雑度が低い場合がある

• メンテナンスがしやすくなるものの、初期開発では時間がかかる

でも絶対テスト書くんでしょ？

TDD再考 (7) – テストはどこまで書けば良いのか？

Beck氏の回答はシンプルである。

「私は機能するコードに対してお金を貰っているのであって、テストコードの対価を受け取っているわけではない。なので自分の哲学としては、テストにかける労力は必要な自信を得るための最小限度に抑えることにしている」

TDDは死んだTDDは死んだ。テスティングよ栄えよ。 by DHHTDDの自殺 by kyon_mm

TDDはオワコンって偉い人が言ってたけど？• Ruby on Rails

• 自動テストの仕組みが組み込まれている• BDDが相対的に有利• ユニットテストはコスト高

• TDDだけを指針にすると全体アーキテクチャが壊れる

• 教条主義、狂信、盲信はよくない• なんだってそうだよね

• やってみて言おう• DHHだって何年もやってから• やったことないなら実践講座へ！

TDDで品質あがる？

テスト駆動開発の効果

IBMドライバ

MicrosoftWindows

MicrosoftMSN

MicrosoftVisualStudio

チーム人数 9 6 5-7 7

コード量(KLOC) 41.0 6.0 26.0 155.2

開発規模(人月) 119 24 46 20

欠陥数(TDD未使用に対する)

61% 38% 24% 9%

開発時間の増加(管理者の見積)

15～20％ 25～35％ 15％ 20～25％

Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through test driven development: results and experiences of four industrial teams” 2008http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

品質 = 欠陥数？

Making Software (2011年)

12章 “How Effective is Test-Driven Development?”

Burak Turhan, Lucas Layman, Madeline Diep, Hakan Erdogmus, Forrest Shull

• 内部品質 – よかったり悪かったり

• 外部品質 – いいけど悪いことも

• 生産性 – なんとも言えない

• テスト品質 – 悪くはなさそう

結論: まだ何とも言えない

TDDで品質上がる？

• たちどころに品質を良くしたい人は壺を買ってください(100万円)

• 自分たちの力で品質を良くしたい人は• 変更があるプロダクトでは、自動回帰テストは確実

に効果がある(コストもかかる)

• TDDはテスト自動化推進の役に立つ(こともある)

• そもそもバグだらけなら、何やっても効果がある(TDDでもいいけどプロセスのほうが…)

TDDの効果は？

• テストを書く習慣と力が付く• チームのディシプリン

• TDDで成功しているチームはある• TDDのよいやり方を学べば効果が期待できる• 使いどころを見極められる

• TDDはフィードバックと見直しのサイクル• 改善を促進する力がある• スキル向上のチャンスも多くなる

• “品質が良くなるという研究があります”！• 上司を説得するのに有効

• まだ疑問が……• 実践講座で話しましょう！

次回 3/3(水)講師は和田さんお待ちしています！