Download as PDF, PPTX
More Related Content
Hey It's Not My TDD!
- 1. Hey It’s not myTDD! 安井力 / やっとむ 「それ俺のTDDとちがう！」 字幕 やっとむ Copyright©2014,2015 安井力/やっとむ All rights reserved.
- 3. 安井 力 /やっとむ プログラマー Java Python Ruby JavaScript テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 コンサルタント モデリング ユーザーストーリー twitter:@yattom facebook:yattom github:yattom bitbucket:yattom
- 5. TDDBC Agile Academy 次回 11/30(月)絶賛募集中！ メイン講師和田卓人 サポート(予定) 安井 力 太田健一郎
- 6.
- 7.
- 9.
- 10. 動作するきれいなコードとは？ • 動作している • バグ対応も、追加変更も容易である •作業が予測可能である • チームに信頼が生まれる
- 11.
- 12.
- 13. TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3.そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5. 2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングを おこなう(Refactor) 7. １〜6を繰り返す
- 14. TDDを支えるツール Unit TestFrameworks xUnit (JUnit, PHPUnit, NUnit, Pytest, …) RSpec Mocha IDE, Refactoring tools Eclipse, IntelliJ Visual Studio Continuous Build / Integration Jenkins Travis 参考: TDD／BDDの思想とテスティングフレームワークの関係を整理しよう(きょん) http://www.atmarkit.co.jp/ait/articles/1403/25/news033.html
- 15.
- 16. BDD向けのツール 振る舞いの記述 (Given/When/Then) RSpec Cucumber, Turnip Behat JBehave Jasmine Web/ブラウザ操作 Selenium WebDriver Geb コミュニケーション Fit / FitNesse
- 17. 振る舞い記述の例 メールを検索する 前提 (Given) “yattom”としてログインしている テスト用メールを100件受信している 受信ボックスを表示している もし (When) 「エラー」を検索する ならば(Then) 「エラー」を含む15件が一覧表示されること
- 18. 振る舞い記述の例 メールを送信する 前提 (Given) “yattom”としてログインしている 受信ボックスを表示している もし (When) yattom2宛にメールを送信する ならば(Then) 送信済みボックスにメールがあること yattom2がメールを受信していること
- 19. 使われてる? 0 10 20 30 40 50 60 70 80 90 2007 2008 20102011 2012 2013 アジャイルプラクティスを使っている割合(%) Daily Standup Unit Testing Retrospectives Continuous Integration TDD Pair Programming State of Agile Survey (VersionOne) http://stateofagile.versionone.com/
- 20.
- 21. テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数 9 65-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
- 22. 保守性への影響 ※1 保守期間(260日間)中、変更要求の対応にかかった工数の平均 "The effectivenessof 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
- 23. TDDの効果の研究をまとめた研究 "Effects of Test-DrivenDevelopment: A Comparative Analysis of Empirical Studies" Simo Makinen and Jurgen Munch, 2013 • 既存の実証研究を調査し、10の内部・外部品 質評価項目で、各研究の結論を整理した • TDDは欠陥の作り込み(introduced defects)を 減らし、メンテナンスしやすいコードを産む • TDDで実装されたコードは、部分的に、サイ ズが小さく、複雑度が低い場合がある • メンテナンスがしやすくなるものの、初期開 発では時間がかかる
- 24.
- 25. 動作するきれいなコードとは？ • 動作している • バグ対応も、追加変更も容易である •作業が予測可能である • チームに信頼が生まれる
- 26.
- 27.
- 28. Which do youlike? https://www.flickr.com/photos/ooocha/3052091706/
- 29. Things got darkerfrom here … ところが……
- 30. A Comparative CaseStudy on the Impact of Test-Driven Development on Program Design and Test Coverage Maria Siniaalto and Pekka Abrahamsson, ESEM, 2007 http://se.inf.ethz.ch/old/teaching/2010-S/0276/slides/pletikosa.pdf 結合度: TDDが悪く見えるけど微妙 凝集度: TDDの経験が足らない テストカバレッジ: TDDは非常に良い
- 31.
- 32.
- 33.
- 34. DHH(デイヴィッド・ハイネマイヤー・ハンソン) Rubyist, Ruby onRailsを作った人 Basecamp (37signals) http://david.heinemeierhansson.com/
- 35.
- 36.
- 37.
- 38. Additionally… TDD damages orbreaks 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やアジャイルの人は テストや品質保証の知識が足らない
- 39.
- 40. Hey It’s not myTDD!
- 41. What are thepossible 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. http://osherove.com/blog/2007/10/8/the-various-meanings-of-tdd.html 「TDD」は4通りに使われている(少なくとも) テストファースト テスト重視 設計手法 開発(+設計も) 人によって違う意味になっている
- 42. What is TDD? Makesure the code works Always have a goal Continuous care of cleanness TDDとは 動くコード 身近なゴール きれいに保つ
- 43. What is TDD,fundamentally? Feedback if the code works Feedback from user’s viewpoint Continuous feedback of what is clean そもそもTDDとは 動くかどうかのフィードバック ユーザ視点からのフィードバック 何がきれいかのフィードバック
- 44. Feedback=Learning You dolearn, throughout the course of a project, about the product, technology, design, team, etc. TDD generates many points of learning フィードバックとは学び 学ぶことはたくさんある TDDは学びのポイントを作る
- 45. Learning ≠ Guaranteeof Success Planning for learning is important Many things are hard to learn by TDD There are cases TDD is not effective / feasible 学ぶだけでは成功しない 何をどうやって学ぶか、計画せよ TDDだけでは足らない
- 46. You need alot for clean code
- 47. TDD is justanother tool Not a silver bullet Can go awry Yet some people do well with TDD TDDは道具にすぎない 銀の弾丸ではない TDDのせいでダメになることも
- 48.
- 49.
- 50. Practice required You mustlearn and practice to be effective “intensively trained for 3 weeks before project C starts” (Tomazˇ Dogsˇa and David Baticˇ, 2013) 素振り重要
- 51. Try and seeBY YOURSELVES 自分で試して判断せよ
- 52.
- 53. My experience I doTDD 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をいつ使うか 直感が働く
- 54. My experience TDD isnot 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は有効
- 55. My experience API, frameworkor 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 複雑なアルゴリズム→ちゃんと設計
- 56. My experience With inadequatelyskilled 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もちゃんと使える
- 57. My experience Anything youare 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使うこともあるよ
- 58.
- 59. Introducing Joseph Founder andArchitect, 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: adaptiveobjectmodel.com) 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開催
- 60. 継続可能な アーキテクチャ Copyright 2014 JosephW. Yoder & The Refactory, Inc. Joseph W. Yoder -- www.refactory.com https://www.slideshare.net/yattom/ss-39226174
- 61. Sustaining Your Architecture 大きな泥のカタマリ 別名:Shantytown(=写真のスラム街の ような都市構造), スパゲッティコード 「大きな泥のカタマリ」は構造が行き当たり ばったりで、とりとめの ない、いいかげんな、 ガムテープと針金でつないだ、スパゲッティ コードのジャングルのこと 標準的ソフトウェアアーキテクチャ でもある。なんでやりたいことと やってることにこんなに差があるのか？ 誰もが高品質なソフトを作りたいのに、 なんで世の中BBoMだらけなのか？
- 62.
- 63.
- 64. Sustaining Your Architecture “～性”要求 アクセシビリティ 互換性 効率性 有効性 拡張性 保守性 パフォーマンス 信頼性 安全性 スケーラビリティ 機密性(セキュリティ) 安定性 サポート性 使用性 「制約」「品質属性」「サービス要求の品質」などに対応 品質は「～性」で表現され、非機能要求とも呼ばれる…… いっぽう、機能要求がどれだけ正しく実現されたかも品質である (こちらはどう計測するのか？)
- 65. Sustaining Your Architecture 品質に関するシナリオとテストを アジャイルプロセスに当てはめる プロダクト ビジョン、 ロード マップ ステークホル ダに提供 機能の 受入テスト バックログを 管理し、 実現する スプリント計画スプリント実行 毎日のレビュー フィードバックを取り込む 重要な品質 シナリオを定める 品質シナ リオも含 む 関連する 品質タス クを含め る 品質の テスト
- 66. You need alot to learn quality
- 67. Don’t Do: Become religiousnor naysayer Mandate TDD Believe everything you hear Numbers don’t lie, people do TDDの信仰も拒絶も良くない TDD必須とか止めよう 言われたことを盲目的に信じない
- 68. TDDの効果の研究をまとめた研究 やっとむ TDD 検索 欠陥は減少生産性は低下 品質は結論できず それがどうした！
- 69.
- 70. Do: Find out yourimpediments Try TDD for solving an impediment With enough training and practice Evaluate and make it better Continue まず障害物を見つける 解消のためTDDを試す(練習も忘れずに) 結果を評価して改善する それを繰り返す
- 71.