Tddのすゝめ

  • 4,365 views
Uploaded on

2011/10/30 NDS 23rd.内で発表した資料。TDDBC 長岡 0.1 ということで発表。

2011/10/30 NDS 23rd.内で発表した資料。TDDBC 長岡 0.1 ということで発表。

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
4,365
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. TDDのすゝめ 2011/10/30NDS 23rd.@まちなかキャンパス長岡 高野 将(TAKANO Sho)
  • 2. TDDのすゝめ =TDDBC 長岡 0.1 2011/10/30NDS 23rd.@まちなかキャンパス長岡 高野 将(TAKANO Sho)
  • 3. TDDBCとは?”TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。”TDDBC Wiki より 今回はセッションだけなので、 0.1
  • 4. まず
  • 5. TDDの素晴らしさを気付かせてくれた、 TDDの伝道師 和田 卓人氏 に感謝 http://twitter.com/#!/t_wada
  • 6. 自己紹介
  • 7. 自己紹介• 氏名:高野 将(TAKANO Sho)• ハンドル:まさる• お仕事:プログラマー兼業主夫• Blog:まさるblog http://blogs.wankuma.com/masaru/• twitter:@masaru_b_cl• facebook:TAKANO.Sho• はてなID:masaru_b_cl
  • 8. 著書 かんたん ASP.NEThttp://gihyo.jp/book/2010/978-4-7741-4306-4
  • 9. Web掲載記事.NET開発を始めるVB6プログラマーが知るべき9のことhttp://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_01/greatblogentry_01_01.html
  • 10. 詳しくは・・・まさるblogで検索してください <(_ _)>
  • 11. TDDのすゝめ
  • 12. TDDとは?
  • 13. TDDとは?“プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き(これをテストファーストと言う)、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。”http://ja.wikipedia.org/wiki/テスト駆動開発 より
  • 14. よくわからん\(^o^)/
  • 15. そんなあなたに
  • 16. TDDのすゝめ
  • 17. 改めて、
  • 18. TDDとは?
  • 19. 安心
  • 20. TDDとは?
  • 21. 着実に一歩ずつ
  • 22. TDDとは?
  • 23. テスト 手法 ではなく開発手法
  • 24. TDDとは?
  • 25. 才能 ではなくスキル
  • 26. TDDの進め方
  • 27. 3つのステップ• Red:失敗するテストを書く• Green:テストを通すようにコードを書く• Refactoring:テストが通る状態を維持し ながら、コードを整理する これら3つのステップを 「小さく」「すばやく」 繰り返し行う
  • 28. ステップ1:Red• 要件を実現するために必要な処理について 「失敗する」テストを書く – コンパイルエラーも失敗に含める• 十分に「小さい」粒度でテストを書く – 大きな問題は小さく分解し、各個撃破していく
  • 29. ステップ2:Green• テストが成功する「最短」のコードを書く• 「すばやく」テストを通すためには定数を返す こともいとわない ✓
  • 30. ステップ3:Refactoring• テストが通る状態を維持したままコードを洗練 させる – 挙動を変えずに構造を変える• 必要があればテストコードも整理する
  • 31. 繰り返し• 三角測量 1つ目のテストと合わせて、より仕様を絞り込 むテストを書く
  • 32. 3つのステップの 繰り返し
  • 33. 3つのステップの繰り返し
  • 34. 3つのステップの繰り返し 着実な道をいく
  • 35. 3つのステップの繰り返し 着実な道をいく 黄金の回転
  • 36. 冒頭の話に戻ると・・・
  • 37. 安心• それまでに書いた全てのコードに対するテス トが存在する → コードを変更した際、どこかが壊れたら すぐにわかる 常にテストに守られているという 「安心」 につながる
  • 38. 着実に一歩ずつ• 小さく、すばやく黄金のサイクルを回す → 小さな目標を少しずつ実現 行き先を定め、一歩進み、足元を固める つまり 「着実に一歩ずつ」 進める
  • 39. テスト手法ではなく開発手法• テストで仕様を表現 → 仕様を満たす最適な設計を導く 主眼は「テスト」ではなく テストを起点に進める 「開発」 にある
  • 40. 才能ではなくスキル• TDDの進め方は3つのステップの繰り返し → やることは決まっているので誰でもできる 才能ではなく、 努力によりTDDの 「スキル」 を身に付ける
  • 41. 3つのステップ以外には
  • 42. 自分が最初のユーザー• 使いやすいか?• 名前がおかしくないか?• 納得できるか?• 人に見られても恥ずかしくないか?• etc... 客観的な視点でコードを見直す
  • 43. TDD三原則 by Uncle Bob• 失敗するユニットテストを成功させるためにしか、 プロダクトコードを書いてはならない。• 失敗させるためにしか、 ユニットテストを書いて はならない。 コンパイルエラーは失敗に数える。• ユニットテストを1つだけ成功させる以上に、 プロ ダクトコードを書いてはならない。Uncle Bob(Robert C. Martin)http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
  • 44. TDD三原則とは• TDD養成ギプス• 原則を守ることで、自動的にTDDにただし、あくまで「原則」であることを忘れずに
  • 45. TDDの 目的
  • 46. 一言でいえば・・・
  • 47. 健康を保つ
  • 48. 健康を保つ• 常にGreenを維持 → 「開発者が認識している」要件を 満たすことが、常に保障される• テスト可能なコード → 他への依存度が低い、つまりは疎結合な コードになるため、変更に強い• 小さい粒度でテスト → 必要最低限のコードしかないため、 理解しやすい• 全てのコードに対するテストの存在 → なにかの拍子に壊しても、すぐにわかる
  • 49. そして・・・
  • 50. コードが健康であれば、開発者の健康も保たれる
  • 51. さらに・・・
  • 52. 個々の開発者が健康であれば チームの健康も期待できる
  • 53. TDDを実践してみて
  • 54. 最初はとにかく写経• まずは「テスト駆動開発入門」を写経すること から始めたテスト駆動開発入門(ケント・ベック著、 ピアソンエデュケーション刊)http://www.amazon.co.jp/dp/4894717115
  • 55. 次は、どういう観点で テストを書くかを学んだ• 「レガシーコード改善ガイド」でテストの書き方 の具体例を学んだレガシーコード改善ガイド(マイケル・C・フェザーズ著、翔泳社刊)http://www.amazon.co.jp/dp/4798116831/
  • 56. 実装コストは多少増加する• プロダクトコード以外にテストコードも書くため、 非TDDに比べると実装に時間がかかるように なった• ただし、最近は慣れてきたこともあり、1.2~ 1.5倍程度で済んでいる印象• そもそも、非TDDの実装完了って本当に完 了?というのもあるので、本当はそこまで差 がないかもしれない
  • 57. 修正コストは減少する• 実装中に積み上げたテストが存在するため、 修正が他に影響したらすぐにわかる• その時点で最もシンプルな設計で実装されて いるため、仕様変更が他の箇所へ影響を及 ぼしにくい
  • 58. 実装時のテンポがよくなる• アプリケーションを動作させるため、「ビルド」 や「デプロイ(配置)」が必要だが、それに非 常に時間がかかるケースがある• TDDでは「ビルド」や「デプロイ(配置)」の待ち 時間がなくなるため、テンポよく実装を進めら れるようになった
  • 59. 機能単位の「単体テスト」は必要• TDDで作成するテストは、最小単位の「Unit Test」• 機能単位の「単体テスト」は相変わらず必要 – 一つの「機能」はいくつもの「処理」の相互作用で 成り立っているため 詳細設計 単体テスト• ただし、非TDDに比べれば、「単体テスト」で検 出されるバグが非常に少ない – 結果として品質が向上する
  • 60. 一つ一つの構成単位が小さくなる• 小さくテストを作成し、実装するということから、 自然とクラス構造やメソッドなど、プログラム の構成単位がシンプルに小さくなる – コード変更の影響が局所化される
  • 61. Demo
  • 62. Demo“「Googleがらみのネタで!」Returns” というテーマにちなみ、 Google発の新プログラミング言語 でTDDのデモを行います
  • 63. Demo FizzBuzz最初のプレイヤーは「1」と数字を発言する。次のプレイヤーは直前のプレイヤーの次の数字を発言していく。ただし、3で割り切れる場合は「Fizz」、5で割り切れる場合は 「Buzz」、両者で割り切れる場合は 「Fizz Buzz」 を数の代わりに発言しなければならない。http://ja.wikipedia.org/wiki/Fizz_Buzz
  • 64. Demoもしもの時のために、事前に実施したものも用意しています。• TDD for FizzBuzz in Dart – Youtube http://www.youtube.com/watch?v=-f6bj-Z59h0• 実際のコード http://try-dart-lang.appspot.com/s/VxIc – 使用したTestRunner http://www.github.com/masaru-b-cl/DartUnit/
  • 65. まとめ
  • 66. 安心
  • 67. 着実に一歩ずつ
  • 68. テスト 手法 ではなく開発手法
  • 69. 才能 ではなくスキル
  • 70. 3つのステップ• Red:失敗するテストを書く• Green:テストを通すようにコードを書く• Refactoring:テストが通る状態を維持し ながら、コードを整理する これら3つのステップを 「小さく」「すばやく」 繰り返し行う
  • 71. 3つのステップの繰り返し 着実な道をいく 黄金の回転
  • 72. 健康を保つ
  • 73. 最後に・・・
  • 74. 次は TDDBC 長岡 0.5予定している内容• 今回の内容をざっと紹介• もうちょっと踏み込んだ実践方法の説明• ライブペアプログラミングしたい
  • 75. というわけで
  • 76. 私とペアプロやらないか?
  • 77. やってもいいよーって方はどんな方法でもいいので 連絡お願いします <(_ _)> こわくないよーーーっ!
  • 78. おしまい明日から早速TDDを実践してみよう!
  • 79. 参考資料、URL• テスト駆動開発入門 (ケント・ベック著、ピアソンエデュケーション刊) http://www.amazon.co.jp/dp/4894717115
  • 80. 参考資料、URL• レガシーコード改善ガイド (マイケル・C・フェザーズ著、翔泳社刊) http://www.amazon.co.jp/dp/4798116831/
  • 81. 参考資料、URL• TDDBC http://devtesting.jp/tddbc/• TDD Boot Camp を開催させていただきました - t- wadaの日記 http://d.hatena.ne.jp/t-wada/20091219/p1• テスト駆動開発チートシート - やさしいデスマー チ http://d.hatena.ne.jp/shuji_w6e/20110429/1304 079615• TDD とは? - TDD.NET http://www.tdd-net.jp/whats-tdd.html
  • 82. 参考資料、URL• TDDワークショップを開催しました - VOYAGE GROUP エンジニアブログ http://tech.ecnavi.co.jp/archives/5052434.html