Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

TDDはじめて物語 Second Season #tddbc

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 87 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à TDDはじめて物語 Second Season #tddbc (20)

Publicité

Plus par Hiroyuki Ohnaka (20)

Plus récents (20)

Publicité

TDDはじめて物語 Second Season #tddbc

  1. 1. Copyright 2017 Hiroyuki Onaka TDDはじめて物語 Second Season 2017/9/30 TDDBC Tokyo 2017-09 大中浩行 この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。
  2. 2. Copyright 2017 Hiroyuki Onaka 突然ですが、ここで問題です 平成28年春期 応用情報技術者試験(午前) より https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_1/2016h28h_ap_am_qs.pdf
  3. 3. Copyright 2017 Hiroyuki Onaka 正解は、こちら
  4. 4. Copyright 2017 Hiroyuki Onaka By National Photo Company [Public domain], via Wikimedia Commons https://en.wikipedia.org/wiki/Bulletproof_vest テストファースト
  5. 5. Copyright 2017 Hiroyuki Onaka では、「テストファースト」とは...? 今日は「テストファースト」をはじめとして、 TDDとは何かについて学んでいきましょう
  6. 6. Copyright 2017 Hiroyuki Onaka アジェンダ • ソフトウェア開発を巡る状況 • TDDとは • TDDの構成要素 • テストファーストとは • きれいなコード • どうテストするか • 明日から役立つお役立ち情報 • なぜTDDするのか
  7. 7. Copyright 2017 Hiroyuki Onaka ソフトウェア 開発を巡る状 況
  8. 8. Copyright 2017 Hiroyuki Onaka http://www.itmedia.co.jp/news/articles/1708/28/news086.html
  9. 9. Copyright 2017 Hiroyuki Onaka 「99%の信頼性を持つスマートフォンを使って いるユーザーには、サービスの信頼性99.99% の場合と、99.999%の場合との違いは分からな いのです。」 Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy. 澤田 武男、関根 達夫、細川 一茂、矢吹 大輔(監訳) 玉川 竜司(訳) 「SRE サイトリライアビリティエンジニアリング」
  10. 10. Copyright 2017 Hiroyuki Onaka 「スライムが強かったらバグ」 「たとえばドラゴンクエストシリーズの序盤で 対戦するモンスターのスライムが、まわりのモ ンスターより強いようなことがあればドラゴン クエストシリーズのお客様視点では異常です。 仕様書に書いてあったとしても指摘すべきで す。」 青山 公士「国民的RPG オンライン化へのチャレンジドラゴンクエストⅩ開発ノウハウ大公開」 (WEB+DB PRESS vol.90)
  11. 11. Copyright 2017 Hiroyuki Onaka • 「品質」というものの捉え方の多様化 • バグのモグラ叩きのなかからは、多様化する 品質への要求に答えることはできない • システム開発の成果物たるプログラムに対す る、内部品質への要求の高まり
  12. 12. Copyright 2017 Hiroyuki Onaka TDDとは
  13. 13. Copyright 2017 Hiroyuki Onaka TDDとは
  14. 14. Copyright 2017 Hiroyuki Onaka https://twitter.com/hisashim/status/913689401825288192
  15. 15. Copyright 2017 Hiroyuki Onaka By Improve It (Flickr: Kent Beck no Workshop Mapping XP.) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons https://en.wikipedia.org/wiki/Kent_Beck Kent Beck
  16. 16. Copyright 2017 Hiroyuki Onaka TDDとは TDDのサイクルは、以下の通りである。 • 小さなテストを追加する。 • すべてのテストを実行し失敗する。 • 変更を行う。 • テストを実行し、成功する。 • 重複を取り除くために、リファクタリングを行う。 ケント・ベック(著)長瀬嘉秀(訳)「テスト駆動開発入門」
  17. 17. Copyright 2017 Hiroyuki Onaka 例題:FizzBuzz 1から100までの数をプリントするプログラムを 書け。ただし3の倍数のときは数の代わりに 「Fizz」と、5の倍数のときは「Buzz」とプリント し、3と5両方の倍数の場合には「FizzBuzz」とプ リントすること。
  18. 18. Copyright 2017 Hiroyuki Onaka テストを追加する。 public class FizzBuzzTest { @Test @DisplayName("3の倍数の時にFizzを返すこと") void _3の倍数の場合にFizzを返すこと() { FizzBuzz fizzBuzz = new FizzBuzz(); assertEquals("Fizz", fizzBuzz.fizzBuzz(3)); } @Test @DisplayName("数をそのまま返すこと") void 数をそのまま返すこと() { FizzBuzz fizzBuzz = new FizzBuzz(); Assertions.assertEquals("4", fizzBuzz.fizzBuzz(4)); } }
  19. 19. Copyright 2017 Hiroyuki Onaka すべてのテストを実行し、新しいテストの失敗を 確認する。
  20. 20. Copyright 2017 Hiroyuki Onaka 小さな修正を行う。 public class FizzBuzz { public String fizzBuzz(int num) { if (num % 3 == 0){ return "Fizz"; } return Integer.toString(num); } }
  21. 21. Copyright 2017 Hiroyuki Onaka すべてのテストを実行し、すべての成功を確認す る。
  22. 22. Copyright 2017 Hiroyuki Onaka フィードバックループ 「運転というのはね、車を正しい方向に走らせ ることじゃないの。常に注意を払って、こっち に行ったら少し戻して、あっちに行ったら少し 戻して、そうやって軌道修正していくものよ」 これがXP のパラダイムだ。注意して、適応して、 変更する。 Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
  23. 23. Copyright 2017 Hiroyuki Onaka TDDの構成要 素
  24. 24. Copyright 2017 Hiroyuki Onaka • xUnitによる自動テスト • アサートファースト • 仮実装・三角測量・明白な実装 • リファクタリング
  25. 25. Copyright 2017 Hiroyuki Onaka xUnitによる自動テスト • 関数やメソッドごとに、エントリーポイント (C言語ならmain関数)をもうけてデバッグす るという、熟練したプログラマーのプラク ティスをフレームワーク化したもの
  26. 26. Copyright 2017 Hiroyuki Onaka xUnit • テストに求められる要素を、フレームワーク 化したもの。Smalltalkのテスティングフ レームワークSUnitがはじまり • JavaのJUnitを始めとして、各言語・各環境 に移植されたものの総称 Kent Beck 「With Patterns」(archive) https://web.archive.org/web/20150315073817/http://www.xprogramming.com/testfram.htm
  27. 27. Copyright 2017 Hiroyuki Onaka xUnitの最も基本となる構成要素 • Fixture • テストケース • チェック • テストスイート
  28. 28. Copyright 2017 Hiroyuki Onaka Fixture/テストケース/チェック/テストスイート (1) • Fixture テストを実行するにあたって準備するものの 総称 • テストケース テストそのものを「オブジェクト」として表 現したもの(JUnitだとメソッド)
  29. 29. Copyright 2017 Hiroyuki Onaka Fixture/テストケース/チェック/テストスイート (2) • チェック アサーションとして実装される self-validating(自己検証可能)であること • テストスイート テストケースを集約して実行する。
  30. 30. Copyright 2017 Hiroyuki Onaka アサートファースト 何から「テストファースト」をはじめるか → テストが最終的に確認すべき結果(アサー ション)から書き始める
  31. 31. Copyright 2017 Hiroyuki Onaka 仮実装・三角測量・明白な実装 • 仮実装 アサーションを書いた後、アサーションを通 すための必要最小限の実装を行う。 • テストの正当性を検証するため(テストのテスト) • テストから最短距離でフィードバックを得るため
  32. 32. Copyright 2017 Hiroyuki Onaka 仮実装・三角測量・明白な実装 • 三角測量 仮実装から本実装を引き出す際に、二つのテス トケースを重ね合わせて実装を導き出す • 明白な実装 テストケースから本実装を明確にイメージでき るときに、テストケースを安全網にして、直接 実装する
  33. 33. Copyright 2017 Hiroyuki Onaka 必要となるフィードバックの度合いに応じて、 「仮実装・三角測量・明白な実装」のどれを用 いるか使い分けていくのがポイントです。
  34. 34. Copyright 2017 Hiroyuki Onaka
  35. 35. Copyright 2017 Hiroyuki Onaka Yu Asano「私のTDDのこころ」より https://www.slideshare.net/uasano/agile-samuraibasecamp-tdd-keynote/43
  36. 36. Copyright 2017 Hiroyuki Onaka リファクタリング • 「コードのあるべき姿」はプログラマーがキー ボードを叩く中であらわれる。アーキテクトが 事前にコードの理想像を示すことはできない • 一度プログラミングしたら、そこで完成なわけ でもない • 「動くコードに触るな」に抗う
  37. 37. Copyright 2017 Hiroyuki Onaka • 継続的にリファクタリングを続けられる、 「動くコードに手を入れられる」のが強い チーム • テストを安全網にすることで、リファクタリ ングを含めて思い切って手を打つことが出来 るようになる。
  38. 38. Copyright 2017 Hiroyuki Onaka テストを安全網にした事例 https://www.slideshare.net/setoazusa/move-to-java8 https://www.slideshare.net/setoazusa/jjug-ccc-bluegreendeployment
  39. 39. Copyright 2017 Hiroyuki Onaka テストファー スト
  40. 40. Copyright 2017 Hiroyuki Onaka TDDの観点から TDDでは、なぜテストファーストするのか
  41. 41. Copyright 2017 Hiroyuki Onaka 「テストファーストしてないテストは怖い」 -@setoazusa
  42. 42. Copyright 2017 Hiroyuki Onaka テストを先に書くことはどんな意味があるのか • テストに求められる機能は、成功するとGreenに なり、そうでない時にRedになること • テストファーストしてないテストは、「まず失 敗させる」ことができないため、テストとして の信頼性がさがる • 「失敗していないテストのカバレッジは50%し かない」
  43. 43. Copyright 2017 Hiroyuki Onaka 思い出してみてください。 自動化されてないテストで、テスト項目書に 「正しく表示されていること」と記載されてい て、検証に苦労したことはありませんか?
  44. 44. Copyright 2017 Hiroyuki Onaka ユニットテストが「テスト」である以上、テス トの答えとなるものは先に用意されているはず
  45. 45. Copyright 2017 Hiroyuki Onaka TDDではなぜテストファーストするのか あくまでテストのあるべき姿を追求したことで、 結果としてテストを最初に書くことになるイ メージ。
  46. 46. Copyright 2017 Hiroyuki Onaka • 大事なのは、システムをデリバリーするために、 どうステップを踏んでいくか • テストファーストを導入できるなら、すればよ い。 • そうでないとしても、ユニットテストより上位 レベルのテストの項目は先に作成するなど、テ スト同士で補完していけば良い。
  47. 47. Copyright 2017 Hiroyuki Onaka ただ、IT技術者として手札は多いほうがよいの で、スキルとしてテストファーストできるにこ したことはないです。
  48. 48. Copyright 2017 Hiroyuki Onaka きれいなコー ド
  49. 49. Copyright 2017 Hiroyuki Onaka 「動作するきれいなコード」 「動作するきれいなコード」、ロン・ジェフ リーズのこの簡潔な言葉は、TDD(テスト駆動 開発)の目標である。動作するきれいなコード は、あらゆる理由で価値がある。 Kent Beck(著) 長瀬 嘉秀(監訳) 「テスト駆動開発入門」
  50. 50. Copyright 2017 Hiroyuki Onaka 「動作するきれいなコード」 「きれいなコード」とは?
  51. 51. Copyright 2017 Hiroyuki Onaka コードとは芸術作品ではない コードとはあくまでサービスとして提供するう えでの設計図 文芸的作品のような美しさ、きれいさよりも解 こうとしているドメインを率直に表現している かのほうが重要ではないのか
  52. 52. Copyright 2017 Hiroyuki Onaka あやうい前提 「実は、『コードのよさは重要だ』という、か なりあやうい前提に基づいて、この本は書かれ ている。」 -「実装パターン」から Kent Beck (著)永田 渉 長瀬 嘉秀(監訳) 「実装パターン」
  53. 53. Copyright 2017 Hiroyuki Onaka 「無能か有能かの判断な んて、結局物事を成功さ せたかどうかでしかない。 勝てば官軍、負ければ賊 軍。無能さを言い訳に努 力しない者は結局何事も 成し遂げず終わる。」 夏海公司「なれる!SE4 誰でも出来る?プロジェクト管理」
  54. 54. Copyright 2017 Hiroyuki Onaka だがしかし • テストしてないけど多分動く • とりあえずデプロイしてみよう • なにかわからないけど動いた
  55. 55. Copyright 2017 Hiroyuki Onaka 「きれいでないコード」が生み出すもの • 成果物として対価を頂いていることに疑問を 抱くような乱れたコードベース • 野戦病院のように開発メンバーの入れ替わり がある疲弊しきった現場 • 天に祈るような気持ちになる爆弾処理のよう なリリース
  56. 56. Copyright 2017 Hiroyuki Onaka ではどうするか 「きれいなコード」ではなく、「きれいでない コード」がなにか、というのははっきりしてい る
  57. 57. Copyright 2017 Hiroyuki Onaka By Wikinaut (Own work (own photo)) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons https://ja.wikipedia.org/wiki/スパゲッティプログラム
  58. 58. Copyright 2017 Hiroyuki Onaka Robert.C.Martin(Uncle Bob) 「プログラマが知るべき97のこと」から
  59. 59. Copyright 2017 Hiroyuki Onaka 「よい」コード 「これまで、粗悪なコードに苦しめられてきた のですから、よいコードが重要であることに間 違いはないのです」 Robert C. Martin (著) 花井 志生 (訳) 「Clean Code アジャイルソフトウェア達人の技」
  60. 60. Copyright 2017 Hiroyuki Onaka 「きれいなコード」とは 今のコードがどのような状況があるか、その コードが周囲にどのような影響を及ぼしている か そこからボトムアップに改善を積み重ねていっ た先に、「きれいなコード」がある
  61. 61. Copyright 2017 Hiroyuki Onaka どうテストす るか
  62. 62. Copyright 2017 Hiroyuki Onaka 「不安をテストで表現する」 http://gihyo.jp/dev/serial/01/tdd/0010
  63. 63. Copyright 2017 Hiroyuki Onaka @t_wada曰く
  64. 64. Copyright 2017 Hiroyuki Onaka 私たちプログラマの手を止めるものは何でしょうか。私は 「不安」だと思っています。「もしかしたら」という感情で すね。「もしかしたら,自分の書いているコードは間違って いるかもしれない」「もしかしたら,ライブラリの使い方が 正しくないかもしれない…」。(略) だから,これから書くコードに対して,if文があるだろうな とか,ループがあるとか,正規表現使わなきゃいけないなと か,そういった自分自身に対する不安,これから書くことに 対する不安に対して,テストを書いていきます。 「[動画で解説]和田卓人の“テスト駆動開発”講座 第10回 テストの最小単位は不安」 http://gihyo.jp/dev/serial/01/tdd/0010
  65. 65. Copyright 2017 Hiroyuki Onaka • プログラマーとしての「不安」 • データベース技術者としての「不安」 • インフラ担当としての「不安」
  66. 66. Copyright 2017 Hiroyuki Onaka 「信頼で結ばれた共同体」 James O. Coplien , Neil B. Harriosn (著), 和智右桂 (翻訳) 「組織パターン」
  67. 67. Copyright 2017 Hiroyuki Onaka 自動テストによる品質の安定がもたらすもの • チーム開発は、開発者だけでなく、多数のス テークホルダーが強調して行うもの • 安定したプロダクトの品質がチーム内相互の 信頼をもたらす
  68. 68. Copyright 2017 Hiroyuki Onaka 明日から役立 つお役立ち情 報
  69. 69. Copyright 2017 Hiroyuki Onaka https://www.flickr.com/photos/okinawa-soba/2951808529/ レガシーコード
  70. 70. Copyright 2017 Hiroyuki Onaka 「プログラマが知るべき97のこと」
  71. 71. Copyright 2017 Hiroyuki Onaka 「不具合にテストを書いて立ち向かう」 不具合にテストを書いて立ち向かう - t-wadaのブログ http://t-wada.hatenablog.jp/entry/debugging-tests
  72. 72. Copyright 2017 Hiroyuki Onaka やはりテストを書いて立ち向かってゆくのです。私 はテスト駆動開発を数年間実践してきた中で、心が けているひとつの「掟」があります。それは「不具 合の修正時には必ず先に不具合を再現する自動テス トを書いてから修正する」というものです。これは もちろん私の発案ではなく、 XP(eXtreme Programming) や TDD の先達から学び、それを 実践するうちに私にも身についてきたものです。
  73. 73. Copyright 2017 Hiroyuki Onaka 結構やってたりする
  74. 74. Copyright 2017 Hiroyuki Onaka 「レガシーコード改善ガイド」
  75. 75. Copyright 2017 Hiroyuki Onaka 仕様化テスト(characterization test) 「仕様化テストは、コードの実際の振る舞いを 明らかにするテストです。『システムはこれを するべきだ』とか『こうしていると思う』とい うことを確認するテストではありません。仕様 化テストは、システムの現在の振る舞いをその まま文章化します。」
  76. 76. Copyright 2017 Hiroyuki Onaka なぜTDDする のか
  77. 77. Copyright 2017 Hiroyuki Onaka TDDはプログラマーの義務?
  78. 78. Copyright 2017 Hiroyuki Onaka だがちょっと待って欲しい 「テストを書く/書かない」ということは、道 義的な責任の問題ではない
  79. 79. Copyright 2017 Hiroyuki Onaka 「テスト」と責任の関係 • テストという工程は、その性格上、品質保証 や、成果物への責任と強い関係をもっている • 「テストを書くべきだ」という論に明快に異 を唱えられる人は少ない
  80. 80. Copyright 2017 Hiroyuki Onaka • 開発プロセスの望ましい姿を論じていたはず が、道義的な責任の問題になってしまう • テストを書く人と書かない人の間の感情的な 対立は、何も生み出さない
  81. 81. Copyright 2017 Hiroyuki Onaka 「TDDやれば偉いわけじゃない」 http://b.hatena.ne.jp/entry/232721484/comment/t-wada
  82. 82. Copyright 2017 Hiroyuki Onaka 幻想を捨てる • カバレッジ100% • ユニットテストを書けばバグがなくなる
  83. 83. Copyright 2017 Hiroyuki Onaka 「テストを書く」ということは、継続的インテ グレーション(CI)や静的解析、コードレビュー やペアプログラミングなど、チーム開発のため のプラクティスと連携して、初めてその力を発 揮する。
  84. 84. Copyright 2017 Hiroyuki Onaka なぜTDDするのか 私の場合…
  85. 85. Copyright 2017 Hiroyuki Onaka 信頼できる成果物のために 「技術力は信頼関係につながる。作業を正確に 見積もり、最初から品質の高いものを届け、高 速なフィードバックループを構築すれば、あな たは信頼されるパートナーになれる。」 Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
  86. 86. Copyright 2017 Hiroyuki Onaka 「君が質の高いソフトウェアを届けることは誰 にも止められない。君が現場に立って、お客さ んに向けてプロジェクトの状況と、プロジェク トに必要なことを誠実に伝えることも誰にも止 められないんだ。」 Jonathan Rasmusson(著) 西村直人・角谷信太郎(監訳) 「アジャイルサムライ 達人開発者への道」
  87. 87. Copyright 2017 Hiroyuki Onaka ありがとうございました! • 大中浩行(Onaka,Hiroyuki) • @setoazusa • グロースエクスパートナーズ株式会社 アーキテクチャソリューション部 テクニカルリード • http://blog.fieldnotes.jp/

×