Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hey It's Not My TDD!


Published on


Published in: Engineering
  • Hi there! Get Your Professional Job-Winning Resume Here - Check our website!
    Are you sure you want to  Yes  No
    Your message goes here

Hey It's Not My TDD!

  1. 1. Hey It’s not my TDD! 安井力 / やっとむ 「それ俺のTDDとちがう!」 字幕 やっとむ Copyright©2014,2015 安井力/やっとむ All rights reserved.
  2. 2. 安井 力 / やっとむ プログラマー Java Python Ruby JavaScript テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 コンサルタント モデリング ユーザーストーリー twitter:@yattom facebook:yattom github:yattom bitbucket:yattom
  3. 3. TDDBC Agile Academy 次回 11/30(月) 絶賛募集中! メイン講師和田卓人 サポート(予定) 安井 力 太田健一郎
  4. 4. t-wada said… 「TDDの の目的は 健康」
  5. 5. TDDとは
  6. 6. 「動作するきれいなコード」、ロン・ジェフ リーズのこの簡潔な言葉は、TDD(テスト 駆動開発)の目標である。動作するきれい なコードは、あらゆる理由で価値がある。 ─ Kent Beck
  7. 7. 動作するきれいなコードとは? • 動作している • バグ対応も、追加変更も容易である • 作業が予測可能である • チームに信頼が生まれる
  8. 8. 動作する、きれいなコードへ きれい 汚い (すぐには)動かない 動作する
  9. 9. 動作する、きれいなコードへ きれい 汚い (すぐには)動かない 動作する 二つの道がある
  10. 10. TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5. 2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングを おこなう(Refactor) 7. 1〜6を繰り返す
  11. 11. TDDを支えるツール  Unit Test Frameworks  xUnit (JUnit, PHPUnit, NUnit, Pytest, …)  RSpec  Mocha  IDE, Refactoring tools  Eclipse, IntelliJ  Visual Studio  Continuous Build / Integration  Jenkins  Travis 参考: TDD/BDDの思想とテスティングフレームワークの関係を整理しよう(きょん)
  12. 12. 振る舞い駆動開発(BDD) 振る舞いを「実行可能な仕様」として記述 振る舞い=機能的な外部仕様 システム全体として提供する 機能にフォーカス Webではブラウザ操作が前提 ユーザーとのコミュニケーション ツールとしての期待
  13. 13. BDD向けのツール  振る舞いの記述 (Given/When/Then)  RSpec  Cucumber, Turnip  Behat  JBehave  Jasmine  Web/ブラウザ操作  Selenium WebDriver  Geb  コミュニケーション  Fit / FitNesse
  14. 14. 振る舞い記述の例 メールを検索する 前提 (Given) “yattom”としてログインしている テスト用メールを100件受信している 受信ボックスを表示している もし (When) 「エラー」を検索する ならば (Then) 「エラー」を含む15件が一覧表示されること
  15. 15. 振る舞い記述の例 メールを送信する 前提 (Given) “yattom”としてログインしている 受信ボックスを表示している もし (When) yattom2宛にメールを送信する ならば (Then) 送信済みボックスにメールがあること yattom2がメールを受信していること
  16. 16. 使われてる? 0 10 20 30 40 50 60 70 80 90 2007 2008 2010 2011 2012 2013 アジャイルプラクティスを使っている割合(%) Daily Standup Unit Testing Retrospectives Continuous Integration TDD Pair Programming State of Agile Survey (VersionOne)
  17. 17. 使われてる? IPA 情報処理推進機構 アジャイル型開発におけるプラクティス活用事例調査
  18. 18. テスト駆動開発の効果 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
  19. 19. 保守性への影響 ※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
  20. 20. TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and Jurgen Munch, 2013 • 既存の実証研究を調査し、10の内部・外部品 質評価項目で、各研究の結論を整理した • TDDは欠陥の作り込み(introduced defects)を 減らし、メンテナンスしやすいコードを産む • TDDで実装されたコードは、部分的に、サイ ズが小さく、複雑度が低い場合がある • メンテナンスがしやすくなるものの、初期開 発では時間がかかる
  21. 21. TDDの効果の研究をまとめた研究 やっとむ TDD 検索
  22. 22. 動作するきれいなコードとは? • 動作している • バグ対応も、追加変更も容易である • 作業が予測可能である • チームに信頼が生まれる
  23. 23. t-wada said… 「TDDの の目的は 健康」
  24. 24. ここらで一服 • みなさんのTDDの経験を教えてください
  25. 25. Which do you like?
  26. 26. Things got darker from here … ところが……
  27. 27. A Comparative Case Study on the Impact of Test-Driven Development on Program Design and Test Coverage Maria Siniaalto and Pekka Abrahamsson, ESEM, 2007 結合度: TDDが悪く見えるけど微妙 凝集度: TDDの経験が足らない テストカバレッジ: TDDは非常に良い
  28. 28. TDDの効果の研究をまとめた研究 やっとむ TDD 検索 良い影響より 影響なしのほうが多い TDDは無意味
  29. 29. Jim Coplien (ジム・コプリン) 『組織パターン』著者 スクラムの成立に影響
  30. 30. 私がFacebookにTDDのことを書いたら すごい爆撃を食らった TDDは悪い設計を生む そういう研究論文が 多数ある TDDより優れた やり方がある 人にTDD勧めるとか お前ふざけんな
  31. 31. DHH(デイヴィッド・ハイネマイヤー・ハンソン) Rubyist, Ruby on Railsを作った人 Basecamp (37signals)
  32. 32. TDDは死んだ テスティングよ栄えよ
  33. 33. きょんさん (うさ耳) テストアーキテクト マサカリが痛い なごや方面
  34. 34. TDDの自殺
  35. 35. Additionally… TDD damages or breaks an architecture TDD people have forgotten the knowledge of testing and quality (as in Quality Assurance) So TDD has little or even negative effects on quality TDDはアーキテクチャを破壊する TDDやアジャイルの人は テストや品質保証の知識が足らない
  36. 36.
  37. 37. Hey It’s not my TDD!
  38. 38. What are the possible meanings of TDD? 1) Test Driven Development: the idea of writing your code in a test first manner. You may already have an existing design in place. 2) Test Oriented Development: Having unit tests of integration tests in your code and write them out either before or after our write the code. Your code has lots of tests. You recognize the value of tests but you don't necessarily write them before you write the code. Design probably exists before you write the code 3) Test Driven Design(the eXtreme Programming way): The idea of using a test-first approach as a fully fledged design technique, where tests are a bonus but the idea is to drive full design from little to no design whatsoever. You design as you go. 4) Test Driven Development and Design: using the test-first technique to drive new code and changes, while also allowing it to change and evolve your design as an added bonus. You may already have some design in place before starting to code, but it could very well change because the tests point out various smells. 「TDD」は4通りに使われている(少なくとも) テストファースト テスト重視 設計手法 開発(+設計も) 人によって違う意味になっている
  39. 39. What is TDD? Make sure the code works Always have a goal Continuous care of cleanness TDDとは 動くコード 身近なゴール きれいに保つ
  40. 40. What is TDD, fundamentally? Feedback if the code works Feedback from user’s viewpoint Continuous feedback of what is clean そもそもTDDとは 動くかどうかのフィードバック ユーザ視点からのフィードバック 何がきれいかのフィードバック
  41. 41. Feedback=Learning  You do learn, throughout the course of a project, about the product, technology, design, team, etc.  TDD generates many points of learning フィードバックとは学び 学ぶことはたくさんある TDDは学びのポイントを作る
  42. 42. Learning ≠ Guarantee of Success Planning for learning is important Many things are hard to learn by TDD There are cases TDD is not effective / feasible 学ぶだけでは成功しない 何をどうやって学ぶか、計画せよ TDDだけでは足らない
  43. 43. You need a lot for clean code
  44. 44. TDD is just another tool Not a silver bullet Can go awry Yet some people do well with TDD TDDは道具にすぎない 銀の弾丸ではない TDDのせいでダメになることも
  45. 45. Kentは最近のFacebookのハッカソンで、半分程度はTDD が適用できたが、残りの半分ではTDDは不適切だったと話し ました。TDDが適用可能なコードでは楽しく作業できたもの の、そうでないパートはやりにくかったそうです。 (中略) Davidの場合は、TDDがうまくいく状況を経験したことは あるものの、彼の仕事のほとんどのケースではうまくいかな いと言います。そんな彼の疑問は、TDDを機能させることに 伴う犠牲は何かということです。多くのプログラマが下手な トレードオフをしています。
  46. 46. TDDの効果の研究をまとめた研究 やっとむ TDD 検索 影響なしが多いなかで よい結果を出しているチームもある TDDは使える
  47. 47. Practice required You must learn and practice to be effective “intensively trained for 3 weeks before project C starts” (Tomazˇ Dogsˇa and David Baticˇ, 2013) 素振り重要
  48. 48. Try and see BY YOURSELVES 自分で試して判断せよ
  49. 49. この話を聞いて、私(Martin)はこれがTDD(あるいは 何らかの技術)を、身を持って知る理想的な姿だと言い ました。まずは試してみて、とことん使った上で、自分 にとってちょうどいい加減を見つける。 (中略) Kentは、(略)プログラマは、どうしても同じことを何度 も何度も繰り返し、物事を複雑にしてもなお、進行中の 機能不全のシステムに固執しすぎるきらいがあります。 Kentは、リブートして原則に戻ることに大賛成です。
  50. 50. My experience I do TDD these days, but not 100% I do test first rather sparingly I confess I don’t write code much anyway … I know when I should do TDD and not 今でもTDDするが100%ではない (実のところあまりコード書いてない) TDDをいつ使うか 直感が働く
  51. 51. My experience TDD is not effective when you have no idea what you want to build Create the big picture by hacking, spiking, BDUF, architecting, anyway you can do In this phase, anything you write are throwaway code TDD works after you have clear goals 何を作るか見当も付かないとTDDは非効率 まず全体像(ハック/アーキテクチャ/事前設計) 目的がはっきりしていればTDDは有効
  52. 52. My experience API, framework or library – TDD works very well, both designing exposed interfaces and internal structures. Simple Web applications – can do but often feels cumbersome. BDD style works best. Complex algorithm – no TDD. Isolate its complexity and define external spec. It’s good if the specs are automated. Then design upfront. You may build up algorithm step by step with TDD, but prepare to discard the code once it’s complete. There’s a chance some of the tests can be reused. API、フレームワーク、ライブラリ→TDD! 簡単なWebアプリ→TDDよりBDD 複雑なアルゴリズム→ちゃんと設計
  53. 53. My experience With inadequately skilled people – TDD helps generating “better” quality code, i.e. at least normal cases run. Test code reviews by senior engineers works great. Abandon hope for really good output. Give them trainings. Those people have a lot of chance of improvement and TDD helps learning. Highly effective team – they say they do TDD but not 100% of the time and you can trust them of the output. It’s the best. スキルが低い開発者→TDDのほうがマシだが、 しっかり面倒見る必要あり すごいチーム→放っておいてよい、 TDDもちゃんと使える
  54. 54. My experience Anything you are not familiar – start with TDD and proceed with caution. As you learn stuff, you can decide what techniques works best. Throwaway code – Do anything you like. I like occasional TDD. よく知らないもの→TDDで始めて、 わかってきたところで判断する 一度切りのコード→ご自由に、 TDD使うこともあるよ
  55. 55. Architecture アーキテクチャという観点
  56. 56. Introducing Joseph Founder and Architect, The Refactory, Inc. Pattern enthusiast, author and Hillside Board President Author of the Big Ball of Mud Pattern Adaptive systems expert (programs adaptive software, consults on adaptive architectures, author of adaptive architecture patterns, metatdata maven, website: Agile enthusiast and practitioner Business owner (leads a world class development company) Consults and trains top companies on design, refactoring, pragmatic testing Amateur photographer, motorcycle enthusiast, enjoys dancing samba!!! 59 Joe Yoder (ジョー・ヨーダー) The Refactory, Inc. パターンの人 PLoP開催
  57. 57. 継続可能な アーキテクチャ Copyright 2014 Joseph W. Yoder & The Refactory, Inc. Joseph W. Yoder --
  58. 58. Sustaining Your Architecture 大きな泥のカタマリ 別名: Shantytown(=写真のスラム街の ような都市構造), スパゲッティコード 「大きな泥のカタマリ」は構造が行き当たり ばったりで、とりとめの ない、いいかげんな、 ガムテープと針金でつないだ、スパゲッティ コードのジャングルのこと 標準的ソフトウェアアーキテクチャ でもある。なんでやりたいことと やってることにこんなに差があるのか? 誰もが高品質なソフトを作りたいのに、 なんで世の中BBoMだらけなのか?
  59. 59. Sustaining Your Architecture すでにBBoMがある どう手をつけたらいい? 汚い部分を局所化するには?
  60. 60. Sustaining Your Architecture コードの模様替え リファクタリングで泥を元に戻せる部分もある。ト レードオフもある。コスト、時間、もしかしたら テクノロジーも。 リファクタリングから良いデザイン (パターン)へ…
  61. 61. Sustaining Your Architecture “~性” 要求 アクセシビリティ 互換性 効率性 有効性 拡張性 保守性 パフォーマンス 信頼性 安全性 スケーラビリティ 機密性(セキュリティ) 安定性 サポート性 使用性 「制約」「品質属性」「サービス要求の品質」などに対応 品質は「~性」で表現され、非機能要求とも呼ばれる…… いっぽう、機能要求がどれだけ正しく実現されたかも品質である (こちらはどう計測するのか?)
  62. 62. Sustaining Your Architecture 品質に関するシナリオとテストを アジャイルプロセスに当てはめる プロダクト ビジョン、 ロード マップ ステークホル ダに提供 機能の 受入テスト バックログを 管理し、 実現する スプリント計画 スプリント実行 毎日のレビュー フィードバックを取り込む 重要な品質 シナリオを定める 品質シナ リオも含 む 関連する 品質タス クを含め る 品質の テスト
  63. 63. You need a lot to learn quality
  64. 64. Don’t Do: Become religious nor naysayer Mandate TDD Believe everything you hear Numbers don’t lie, people do TDDの信仰も拒絶も良くない TDD必須とか止めよう 言われたことを盲目的に信じない
  65. 65. TDDの効果の研究をまとめた研究 やっとむ TDD 検索 欠陥は減少 生産性は低下 品質は結論できず それがどうした!
  66. 66. ユニットテストはムダだ(ほとんど)
  67. 67. Do: Find out your impediments Try TDD for solving an impediment With enough training and practice Evaluate and make it better Continue まず障害物を見つける 解消のためTDDを試す(練習も忘れずに) 結果を評価して改善する それを繰り返す
  68. 68. おしまい