CodeZineAcademy TDD実践講座PR資料
2 likes•2,342 views
デブサミ2016(2016/2/18)でCodeZineAcademyの紹介セッションで、TDD実践講座の紹介をするための資料です。 #devsumi
CodeZineAcademy TDD実践講座PR資料
- 2. TDD実践講座
- 4. タイムテーブル 1. TDDのこころ (講義) 2. TDDデモ＆チュートリアル 3. TDD体験セッション 4. 全体コードレビュー 5. TDD応用編 (講義) 6. ふりかえり
- 10. 太田 健一郎 株式会社 SHIFT Test Automator Jenkins Selenium Geb JavaScript テスト自動化 CI twitter:@oota_ken facebook:oota.ken github:ootaken
- 12. 安井 力 / やっとむ twitter:@yattom https://www.facebook.com/yattom プログラマー Java Python Ruby JavaScript テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 コンサルタント モデリング
- 13. 16 The Scrum Field Guide (Mitch Lacey) 和訳が出ます！ (安井力、近藤寛喜、原田騎郎 訳) 「本書はガイドとして、スクラム の初歩から熟達に向け、現実的な 方法を指導してくれる。 …より高度で実践的な、スクラム フレームワークをあなた自身とあ なたのチームで機能させるための ガイドだ。」 (ジム・ハイスミス) 発売日: 2月26日 予価: 3,480円 マイナビ出版 Amazon.co.jpにて予約受付中！
- 14. カンバン仕事術 ―チームではじめる 見える化と改善 (Kanban In Actionの翻訳) 発売日: 3月25日 予価: 3,888円 オライリージャパン Amazon.co.jpにて予約受付中！
- 17. ペアプログラミングとは "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人で会話することだ(設計もテス トも同時にする)。会話するのは、もっと上手にプログ ラムするためである。」
- 19. ふりかえり
- 20. Keep(よかったこと)の例 • TDDがどういうものなのか理解できた ※誤った認識を今まで持っていた…… • 今日学習した黄金のサイクルは今後も 意識的に続けていこうと思った。 • 気づかないうちにチェックされていた →必要なときに正に指摘を受けた
- 21. Try(これからやりたいこと)の例 • 新規のプロジェクトでTDDを導入してみ ようと思う • 自宅で復習と理解を深めるためにビール を飲みながら独りTDDをやってみる • 今日から写経をはじめます
- 22. 体験しないとわからない
- 23. TDDの特徴 • 体験しないとわからない (ペアプロも) • 練習すれば上達する • 状況、対象、設計、スキルなどに応じて 幅広い様々な手法、アプローチがある
- 24. TDD実践講座の特徴 • 体験しないとわからない (ペアプロも) • 練習すれば上達する • 状況、対象、設計、スキルなどに応じて 幅広い様々な手法、アプローチがある • 体験できる(ペアプロも) • 練習を始めるきっかけになる • 熟練者、経験者に具体的相談ができる
- 25. TDDBC(TDD Boot Camp) • コミュニティによるイベント • ボランティア講師・ＴＡ • ハイレベル(な人も来てくれる)！ • 土日 半日～1日 • 全国で不定期に開催 • 無料！ • 2/27(土) 東京 https://tddbc.doorkeeper.jp/
- 26. よくある質問
- 27. TDDはテストですか
- 28. TDDはテスト手法か？ • テスト駆動開発 ＝ 開発手法 • TDDはテストの代わりにならない • 部分的に担保できることもある • TDDで書いたテストも積極的に整理(削除)する • 「TDDだからテストしないよ！」 ちょっとそこに座れ っていうか実践講座来なさい
- 30. テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数 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” 2008 http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
- 31. 保守性への影響 ※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
- 32. TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and Jurgen Munch, 2013 • 既存の実証研究を調査し、10の内部・外部品質評 価項目で、各研究の結論を整理した • TDDは欠陥の作り込み(introduced defects)を減 らし、メンテナンスしやすいコードを産む • TDDで実装されたコードは、部分的に、サイズが 小さく、複雑度が低い場合がある • メンテナンスがしやすくなるものの、初期開発で は時間がかかる
- 33. でも絶対テスト書くんでしょ？ TDD再考 (7) – テストはどこまで書けば良いのか？ Beck氏の回答はシンプルである。 「私は機能するコードに対してお金を 貰っているのであって、テストコードの対 価を受け取っているわけではない。なので 自分の哲学としては、テストにかける労力 は必要な自信を得るための最小限度に抑え ることにしている」
- 34. TDDは死んだ TDDは死んだ。テスティングよ栄えよ。 by DHH TDDの自殺 by kyon_mm
- 35. TDDはオワコンって 偉い人が言ってたけど？ • Ruby on Rails • 自動テストの仕組みが組み込まれている • BDDが相対的に有利 • ユニットテストはコスト高 • TDDだけを指針にすると 全体アーキテクチャが壊れる • 教条主義、狂信、盲信はよくない • なんだってそうだよね • やってみて言おう • DHHだって何年もやってから • やったことないなら実践講座へ！
- 36. TDDで品質あがる？
- 37. テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数 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” 2008 http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
- 38. 品質 = 欠陥数？ Making Software (2011年) 12章 “How Effective is Test-Driven Development?” Burak Turhan, Lucas Layman, Madeline Diep, Hakan Erdogmus, Forrest Shull • 内部品質 – よかったり悪かったり • 外部品質 – いいけど悪いことも • 生産性 – なんとも言えない • テスト品質 – 悪くはなさそう 結論: まだ何とも言えない
- 39. TDDで品質上がる？ • たちどころに品質を良くしたい人は 壺を買ってください(100万円) • 自分たちの力で品質を良くしたい人は • 変更があるプロダクトでは、自動回帰テストは確実 に効果がある(コストもかかる) • TDDはテスト自動化推進の役に立つ(こともある) • そもそもバグだらけなら、何やっても効果がある (TDDでもいいけどプロセスのほうが…)
- 40. TDDの効果は？ • テストを書く習慣と力が付く • チームのディシプリン • TDDで成功しているチームはある • TDDのよいやり方を学べば効果が期待できる • 使いどころを見極められる • TDDはフィードバックと見直しのサイクル • 改善を促進する力がある • スキル向上のチャンスも多くなる • “品質が良くなるという研究があります”！ • 上司を説得するのに有効 • まだ疑問が…… • 実践講座で話しましょう！