テスト駆動開発入門

6,255 views
5,988 views

Published on

札幌Javaカンファレンス2012での発表資料。

Published in: Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,255
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
59
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide
  • \n
  • 30秒程度\n
  • \n
  • \n
  • \n
  • \n
  • 従来のやり方の問題\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 具体的には?\n
  • \n
  • \n
  • FizzBuzzのデモ\n
  • FizzBuzzのデモ\n
  • よくわからない、むずかしい⇒目的と効果\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 習得できるスキルである\n
  • 銀の弾丸ではない\n
  • 習得できる\n
  • TDDをはじめるワケ\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • TDDのこころ\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 学ぶためには?\n
  • 学ぶためには?\n
  • \n
  • \n
  • テスト駆動開発入門

    1. 1. テスト駆動開発入門2012.11.17 札幌Javaカンファレンス2012 渡辺修司(@shuji_w6e) 1
    2. 2. 自己紹介
    3. 3. 渡辺 修司Javaプログラマ 株式会社エスプラニング所属 ウェブアプリやデスクトップアプリの開発テスト駆動開発、ユースケース駆動開発アジャイル開発最近の趣味はロードバイクとフットサル
    4. 4. @shuji_w6e札幌 JavaコミュニティTDD Boot Campやさしいデスマーチ(Blog)執筆活動 WEB DB Press vol.69 JUnit実践入門(11/21)
    5. 5. テスト駆動開発とは?
    6. 6. テストファースト動作するきれいなコード設計を駆動する開発手法
    7. 7. ソフトウェア開発の流れ ユーザ要求定義(要件定義) システム要求定義(外部設計) 詳細設計・プログラミング テスト(評価)
    8. 8. ソフトウェア開発の流れ ユーザ要求定義(要件定義) システム要求定義(外部設計) 詳細設計・プログラミング 単体テスト テスト(評価)
    9. 9. V字モデル 要件定義 受入テスト 外部設計 システムテスト 内部設計 結合テスト プログラム設計 単体テスト
    10. 10. 単体テスト(理想)詳細設計(内部設計)でプログラムの品質を高め、手戻りを減らす詳細設計のレビューを実施することで品質を高めるプログラミングは単純作業詳細設計が正しく実装されているかを検証
    11. 11. 単体テスト(現実)ソフトウェアは複雑 詳細設計やってみなければ解らないプロトタイピング 実装実装のテストになる詳細設計がテストされない 単体テスト
    12. 12. 単体テスト(現実)ソフトウェアは複雑 詳細設計やってみなければ解らないプロトタイピング ? 実装実装のテストになる ? 単体テスト詳細設計がテストされない
    13. 13. 単体テスト(現実)ソフトウェアは複雑 詳細設計やってみなければ解らないプロトタイピング ? 実装実装のテストになる ? 単体テスト詳細設計がテストされない単体テストが機能していない?
    14. 14. V字モデルの問題点完璧な詳細設計を先に行うのは難しいため、確実に手戻りが発生する詳細設計をテストすべき単体テストが実装をテストしている
    15. 15. http://www.flickr.com/photos/alisdair/135306281/
    16. 16. テスト駆動開発のサイクル 1.設計する5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
    17. 17. テストファースト原則としてテストを先に書くテストファーストがベスト設計が机上でまとまらない場合プロトタイプを作ってみるテストを書くプロトタイプを捨てるか利用するか決める
    18. 18. http://www.flickr.com/photos/snowyuki/5223599006/
    19. 19. FizzBuzz 1から100までの整数を順番に出力する ただし、 値が3の倍数の場合は「Fizz」を 値が5の倍数の場合は「Buzz」を 値が3と5の公倍数の場合は「FizzBuzz」を それぞれ表示すること
    20. 20. http://www.flickr.com/photos/alisdair/2398525854/
    21. 21. テスト駆動開発のサイクル 1.設計する5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
    22. 22. 動作するきれいなコードきれい 汚い 動かない 動く
    23. 23. 1.設計する 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させるきれい 3.コードを書く汚い 動かない 動く
    24. 24. 2.テストを書く 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させるきれい 3.コードを書く汚い 動かない 動く
    25. 25. 3.コードを書く 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させるきれい 3.コードを書く汚い 動かない 動く
    26. 26. 4.テストを成功させる 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させるきれい 3.コードを書く汚い 動かない 動く
    27. 27. 5.リファクタリング 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させるきれい 3.コードを書く汚い 動かない 動く
    28. 28. 1.設計する 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させるきれい 3.コードを書く汚い 動かない 動く
    29. 29. デモ http://www.flickr.com/photos/snowyuki/5223599006/
    30. 30. http://www.flickr.com/photos/palermobootcamp/5464512672/
    31. 31. http://www.flickr.com/photos/jas_132/5403388208
    32. 32. http://www.flickr.com/photos/sirod47/5538908868/
    33. 33. ソフトウェア開発は楽しい創造的労働実際に動くモノをゼロから作れる。期待通りに動けば嬉しい。知的労働アイディアをモノに反映できる。難しい問題を解決できれば嬉しい。
    34. 34. スキル不足仕様変更 経験不足複雑な要件 不安 http://www.flickr.com/photos/yopse/3772030400/
    35. 35. テスト駆動開発コードが満たす条件が明確になるコード変更時の影響が見える自然と疎結合な設計になる積極的なリファクタリングを行える自動化され、繰り返して実行できる
    36. 36. テスト駆動開発コードが満たす条件が明確になるコード変更時の影響が見える自然と疎結合な設計になる積極的なリファクタリングを行える自動化され、繰り返して実行できる 開発時の不安が軽減できる!
    37. 37. 反復的な開発 ユニットテスト プログラミング 詳細設計反復的にテスト・設計・プログラミング素早いフィードバックで変更に強くなる
    38. 38. 反復的な開発 ユニットテスト プログラミング 詳細設計反復的にテスト・設計・プログラミング素早いフィードバックで変更に強くなる アジャイル的な手法
    39. 39. 反復的な開発 ユニットテスト テスト駆動開発 プログラミング 詳細設計反復的にテスト・設計・プログラミング素早いフィードバックで変更に強くなる アジャイル的な手法
    40. 40. なぜ、TDDを実践するか?ソフトウェアは思った以上に複雑パーフェクトプログラマなんかいない不安だからユニットテストを書くセーフティネットとしてのユニットテストすばやく回し、すばやいフィードバック
    41. 41. セーフティネット http://www.flickr.com/photos/32010000@N08/2987901256/
    42. 42. 設計を駆動する開発手法 http://www.flickr.com/photos/86921622@N00/281632021/
    43. 43. テスタビリティ状態や副作用戻り値予測可能なオブジェクト疎結合
    44. 44. テスタビリティ状態や副作用戻り値予測可能なオブジェクト疎結合 よい設計であればテストしやすい
    45. 45. テスト駆動の真実 1.設計する5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
    46. 46. テスト駆動の真実 1.設計する5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
    47. 47. テスト駆動の真実 1.設計する5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
    48. 48. http://www.flickr.com/photos/terrydonaghe/1117999/
    49. 49. 小さく個別にすばやく
    50. 50. ひとつずつ、一歩ずつ小さなステップで大きなものは小さく分割確実に、堅実に手戻りを小さく
    51. 51. ひとりずつ、仕留めるテストは個別撃破する次のテストを作らない
    52. 52. すばやくまわす 1.設計する小さく回す 5.リファクタリング早く回す Heuristicsすぐに対応 2.テストを書くリズム重要 4.テストを成功させる 3.コードを書く
    53. 53. 使う 作る伝える
    54. 54. 自分が最初のユーザー使いにくいものは使いにくい自分で評価する納得できるか?恥ずかしくないか?解りやすいか?
    55. 55. 道具にこだわる最高のパフォーマンスを維持するプロとしてのこだわり少しでも使いやすく日々、研究・工夫
    56. 56. 未来の自分が読むテストコードは保守される読みにくいコードは悪シンプルに名前重要型
    57. 57. http://www.flickr.com/photos/akikophotography/530984398/
    58. 58. とにかく書くパターン化しやすいので習得しやすいテスティングフレームワークを活用するテスト技法を学び幅を広げる http://www.flickr.com/photos/akikophotography/530984398/

    ×