テスト駆動開発へようこそ

11,004 views

Published on

TDD BootCamp 旭川(2014.02.01)の講演資料

Published in: Technology
2 Comments
40 Likes
Statistics
Notes
  • なお、Uncle Bob の TDD 三原則 (その実は「テストファースト三原則」) に従うなら、次のようなやり方は TDD ではありません。

    ・不安だったのでユニットテストを追加してみたらグリーンだったが、そのままテストを残した
    [原則2に違反]

    ・最初にユニットテストを全部書いてから、プロダクトコードに取り掛かった
    [まず間違いなく重複するユニットテストが存在するので原則3に違反]

    ☆ TDD は最小限のユニットテストでカバレッジ 100% ☆


    注: 原則3の元々の意味は、「テストを満たす以上にプロダクトコードを書くな! その部分はテストされていないことになるのだから」というものです。例えば、プロダクトコードを書いているときに、「あっ! エラー処理が抜けてるじゃないか! 書いておかなきゃ」と、ユニットテストを書かずにエラー処理の記述もやってしまうような場合です。TDD はアジャイル開発のひとつである XP から出てきたため、「先にユニットテストを全部書く」などというウォーターフォール的な発想とは無縁で、ゆえにそれを明確に否定する言葉も持たないのですが、あえて持ち出すならばこの原則3が該当するでしょう。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Uncle Bob の TDD 三原則 (p.15)
    > 失敗するユニットテストより先にプロダクショ ンコードを書いてはならない
    >テストケースのコンパイルが通り、適切に失 敗するまでは次のテストケースを書いてはならない
    >すべてのテストケースが成功するまでは次の プロダクションコードを書いてはならない

    この出典が不明です。Uncle Bob がどこでそんなことを言った(書いた)のか?

    TheThreeRulesOfTdd http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
    に掲載されているものが、Uncle Bob の書いた TDD 三原則。

    1. You are not allowed to write any production code unless it is to make a failing unit test pass.
    2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
    3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

    これを訳したというのであれば、p.15は明らかな誤訳です。

    これの翻訳なら、やっとむ氏のものが良いかと。
    http://www.tdd-net.jp/2009/08/tdd-9534.html

    1. 失敗するユニットテストを成功させるためにしか、プロダクトコードを書いてはならない。
    2. 失敗させるためにしか、ユニットテストを書いてはならない。コンパイルエラーは失敗に数える。
    3. ユニットテストを1つだけ成功させる以上に、プロダクトコードを書いてはならない。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
11,004
On SlideShare
0
From Embeds
0
Number of Embeds
521
Actions
Shares
0
Downloads
65
Comments
2
Likes
40
Embeds 0
No embeds

No notes for slide

テスト駆動開発へようこそ

  1. 1. テスト駆動開発へ ようこそ 2014.02.01 TDD BootCamp 旭川 Shuji Watanabe (@shuji_w6e) #tddbc 1
  2. 2. 自己紹介
  3. 3. 渡辺 修司 / @shuji_w6e 札幌Javaコミュニティ やさしいデスマーチ JUnit実践入門 Java, Groovy, JavaScript, AWS, TDD ロードバイク、スノーボード
  4. 4. 最近のお仕事... 昨年8月に転職 株式会社クラスメソッド 札幌にて在宅勤務 AWS利用者向けシステムの開発 主にフロントエンドや自動化などを担当 Spring, Ember.js, d3-data ブログ業務
  5. 5. TDDBCへ ようこそ
  6. 6. 本日のスケジュール 11:00∼12:15 TDD, ユニットテストに関する講演 12:15∼12:30 ペアプロとお題の説明 12:30∼13:30 ペア作成、昼食、自己紹介など 13:30∼15:00 演習(前半) 15:00∼15:30 レビュー① 15:30∼17:00 演習(前半) 17:00∼17:30 レビュー② 17:30∼17:50 振り返り ※休憩やお手洗いはご自由にお取りください
  7. 7. TDD Boot Camp(TDDBC) とは、テスト 駆動開発(Test Driven Development)につ いて、座学だけでなく、実習形式で手を 動かして体得することを目的とするイベ ントです。 http://devtesting.jp/tddbc/
  8. 8. 旭川発上陸
  9. 9. TDDBCで体験して欲しいこと テストファースト ユニットテスト リファクタリング TDDのサイクル ペアプログラミング コードレビュー
  10. 10. グリーンバンド acts_as_professional
  11. 11. テスト駆動開発
  12. 12. テスト駆動開発とは? ソフトウェアの開発手法 テスト駆動開発の1サイクル はじめにテストコードを書く テストが成功する必要最低限のコードを書く テスト成功を維持してリファクタリングする 上記サイクルを素早くテンポ良く繰り返す
  13. 13. TDDのサイクル 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
  14. 14. TDD三原則 - Uncle Bob 失敗するユニットテストより先にプロダクショ ンコードを書いてはならない テストケースのコンパイルが通り、適切に失 敗するまでは次のテストケースを書いてはな らない すべてのテストケースが成功するまでは次の プロダクションコードを書いてはならない
  15. 15. TDD 品質保証テスト 品質保証テストはソフトウェアを対象とし、 品質担当者が高い品質を担保するために実施 TDDは品質を担保するわけではない 結果的に品質は高まるが主目的ではない 開発者が安心して開発できるための開発手法 TDDは設計やプログラム自体を対象とする
  16. 16. 汚いコードは動かない 密結合 多重ネスト 巨大なクラス 多すぎる引数 多すぎる責務
  17. 17. きれいな動くコードへの道 きれい 汚い 動かない 動く
  18. 18. 1.設計する 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる きれい 3.コードを書く 汚い 動かない 動く
  19. 19. 2.テストを書く 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる きれい 3.コードを書く 汚い 動かない 動く
  20. 20. 3.コードを書く 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる きれい 3.コードを書く 汚い 動かない 動く
  21. 21. 4.テストを成功させる 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる きれい 3.コードを書く 汚い 動かない 動く
  22. 22. 5.リファクタリング 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる きれい 3.コードを書く 汚い 動かない 動く
  23. 23. 1.設計する 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる きれい 3.コードを書く 汚い 動かない 動く
  24. 24. TDDのこころ ©t-wada
  25. 25. 小さく 個別に すばやく
  26. 26. ひとつずつ、一歩ずつ 小さなステップで 大きなものは小さく分割 確実に、堅実に 手戻りを小さく
  27. 27. ひとりずつ、仕留める テストは個別撃破する 次のテストを作らない
  28. 28. すばやくまわす 小さく回す 1.設計する 5.リファクタリング 早く回す Heuristics すぐに対応 リズム重要 2.テストを書く 4.テストを成功させる 3.コードを書く
  29. 29. 使う 作る 伝える
  30. 30. 自分が最初のユーザー 使いにくいものは使いにくい 自分で評価する 納得できるか? 恥ずかしくないか? 解りやすいか?
  31. 31. 道具にこだわる 最高のパフォーマンスを維持する プロとしてのこだわり 少しでも使いやすく 日々、研究・工夫
  32. 32. 未来の自分が読む テストコードは保守される 読みにくいコードは悪 シンプルに 名前重要 型
  33. 33. どうして、 テスト駆動開発を 導入するのか?
  34. 34. スキル不足 仕様変更 経験不足 複雑な要件 不安 http://www.flickr.com/photos/yopse/3772030400/
  35. 35. 安全を確保する http://www.flickr.com/photos/32010000@N08/2987901256/
  36. 36. なぜ、TDDを実践するか? ソフトウェアは思った以上に複雑 パーフェクトプログラマなんかいない 不安だからユニットテストを書く セーフティネットとしてのユニットテスト すばやく回し、すばやいフィードバック
  37. 37. TDDが目指すところ 安心できる健康な開発 変更に強い健康なコード
  38. 38. 難しそう・・・ http://www.flickr.com/photos/k1netik/50298297/
  39. 39. TDDはスキル 最初から完璧に出来る人はいない 原則は原則、出来る所から少しずつ 困ったら「TDDのこころ」を見直す 息を吸うようにテストコードを書き、
 息を吐くようにプロダクトコードを書こう
  40. 40. TDDをはじめよう
  41. 41. TDDをはじめるワケ 設計力が高くなる コードに自信が持てる! 1人でもはじめられる 開発が楽しくなる!!
  42. 42. TDDBCではじめるワケ TAがいるから安心 1人で悩む必要がない 解らない事はみんなで考える 他のチームのコードを見ることができる
  43. 43. TDDBCの心得 http://www.flickr.com/photos/terrydonaghe/1117999/
  44. 44. 1.手を動かす http://www.flickr.com/photos/esti/4638056301/
  45. 45. 2.議論する http://www.flickr.com/photos/86921622@N00/281632021/
  46. 46. 3.楽しむ http://www.flickr.com/photos/monmo/21100814/
  47. 47. 4.現実と戦う http://www.flickr.com/photos/panoptikon/403903803/
  48. 48. ユニットテストが不安
  49. 49. ユニットテスト入門
  50. 50. ユニットテストとは? システムを構成する最小部品のテスト
 クラスやメソッドが対象 期待された振る舞いをするかを検証する テストプログラムを作り自動化する
 テスティングフレームワーク JUnit pyunit 最も基本的なテストなので最初に習得すべき
  51. 51. テストのポイント 特定の条件下で検証する(Test Case) 本来はどうあるべきか?(Expected) 実際にどうなっているのか?(Actual)
  52. 52. 4フェイズテスト 1. 事前準備 (Setup)
 事前条件や必要なデータを作成する 2. 実行 (Exercise)
 対象となるメソッドを1回だけ呼び出す 3. 検証(Verify)
 期待値と実測値を比較する 4. 後処理(TearDown)
  53. 53. ユニットテストのポイント テスト対象クラスに対しテストクラスを作成 テストケースで操作するのは1つのメソッド 事前条件と実行を混同しない 検証は細かく行い、問題を切り分ける
  54. 54. 事前設計とテストファースト 外部的システムの振る舞い(システム境界) プログラムのインターフェイス 内部的処理(private メソッド) システム境界 IN インターフェイス 内部的処理 内部的処理 OUT 内部的処理 内部的処理
  55. 55. リファクタリング ユニットテストの最大の目的のひとつ 外部的振る舞いを壊さずに実装を変更 privateメソッドのテストをしない
  56. 56. デモ

×