Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テスト駆動開発入門

yattom
September 29, 2018

 テスト駆動開発入門

テスト駆動開発(TDD)の入門です。
TDDBC Tokyo 2018の基調講演資料です。
(TDDBC当日の編集や、後日のフィードバックを反映しています。そのため基調講演時から一部変更されています。)

yattom

September 29, 2018
Tweet

More Decks by yattom

Other Decks in Programming

Transcript

  1. 安井 力 / やっとむ twitter:@yattom https://www.facebook.com/yattom プログラマー Java Python Ruby

    JavaScript テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 ゲームを作って一緒に遊ぶ 宝探しアジャイルゲーム、 カンバンゲーム、 心理的安全性ゲーム
  2. TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5.

    2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングを おこなう(Refactor) 7. 1〜6を繰り返す
  3. 計算機の仕様 • 足し算ができる • [x] 引き算ができる • 掛け算ができる • [x]

    割り算ができる • [x] 計算できないときはエラーにする
  4. Uncle Bob said … 「クズコードを書くのは もうやめだ」 「顧客のため 最高のコードを書く」 「上司のため 最高のテストを書く」

    「チームのため すべてテストを書く」 「上達するため 練習を積む」 Software Craftsmanship: What it's all about.
  5. 余談: TDDのテストはテストじゃない…? • TDD=開発手法≠テスト手法 • でもテスト書いてるじゃんね • 単純な事実: TDDで書いたテストは 必要なテストすべてを

    網羅しない可能性がある (網羅したかったら 網羅するように 書かないといけない) https://www.slideshare.net/goyoki/votddtdd-tdd-on-live
  6. Why TDD? ― TDDが解決する問題 • テストがない • テストを書かない • ユーザー視点が欠ける

    • 最善の解を探せない • チーム内でやり方がバラバラ • 機能変更や追加が大変 • 引き継ぎができない
  7. Why TDD? ― TDDの効果 • テストがある • テストが書ける • ユーザー視点を持てる

    • 試行錯誤を通じて最善の設計に近づける • チームのレベルが上がる • 機能変更や追加が容易になる • 意図を残せる
  8. Why TDD? ― 人間の問題 プ ユ プ プ 他の人に 理解してもらう

    使い方を 把握する 利用者の視点 を持つ 作業分担して 協力する 動作する きれいなコード
  9. 余談 ― 結合の問題 • テストレベル • ユニット ≒ 自分1人の仕事をテストする •

    結合 ≒ 2人以上の仕事を組み合わせてテストする • システム ≒ 実際に使うユーザーの観点でテストする
  10. Why TDD? ― 変更容易性の問題 • 設計が複雑化する • ドキュメントが陳腐化する • 全体を把握しきれなくなる

    • どこを直せばいいか自信がなくなる • 全体を理解していないので、つぎはぎで直す • 直した場所と関係なさそうなところが壊れる • ますます設計が複雑化する
  11. Why TDD? ― テストを残す • 将来たくさん変更するなら、毎回テストも必要 • 大規模なプログラムでは、変更の影響範囲把握が難しい → テストは毎回、すべてやりたい

    回帰テスト • 質問: 将来に渡り、同じテストを100回やるとします 手でやるのと、自動テストにするのと、どっちが好き?
  12. Why TDD? ― 不安を取り除く • 動くか不安 → テストする • 異常な入力でも平気だろうか

    → テストする • 動かしたら遅いかも → テストする • 新しい機能は、元からある機能と不整合しないかな? → テストする • このライブラリどう使うんだろう → テストする • 変なコードだけどどんな結果になるのかな → テストする • こう動くと思うんだけど → テストする • こう書けばいいのかな → テストする • 面倒くさいしこれでいいや → テストする • ねむいつかれたかえりたい → テストする
  13. 素因数分解の分解 • [ ] 1を素因数分解すると→1 • [ ] 2を素因数分解すると→2 •

    [ ] 6を素因数分解すると→2, 3 • 3を素因数分解すると→3
  14. 素因数分解の分解 • 1の場合(特殊) • [ ] 1を素因数分解すると→1 • 素数の場合 •

    [ ] 2を素因数分解すると→2 • 3を素因数分解すると→3 • 複合の場合 • [ ] 6を素因数分解すると→2, 3
  15. リファクタリングの対象 • コードをきれいにする • メソッド名、変数名 • インデント • コメント •

    設計も見直す • プロダクトコードもテストコードも見直す • 常にやり続ける • 「動くコード」を保証するテストが前提 大
  16. リファクタリングは可逆変換 • 変数名やメソッド名の変更 • 処理の一部をメソッド化する ⇔ メソッドをインライン化する • 一時変数を導入する ⇔

    変数をインライン化する • データを移動する ⇔ オブジェクトをくくり出す ⇔ メソッドを移動する • 条件記述を分割する ⇔ 条件記述を統合する • その他いろいろ リファクタリングを使って 「動作するもっともシンプルなコード」を 模索する
  17. すでにきれいじゃないときは • 直して祈る 保護して変更する • 「シーム(縫い目、接合部)」を見つける • 第6章 時間がないのに変更しなければなりません •

    第9章 このクラスをテストハーネスに入れることができま せん • 第11章 変更する必要がありますが、どのメソッドをテスト すればよいのでしょうか? • 第16章 変更できるほど十分に私はコードを理解していま せん • 第21章 同じコードをいたるところで変更しています • 第24章 もうウンザリです。何も改善できません
  18. ここまでのまとめ ― リファクタリング • リファクタリングできれいを保つ • きれい=Clean 美醜ではない • TDDサイクルの一部として、常にやる

    • コードも、テストも、設計もリファクタリングする • 試行錯誤と設計の改善 • 設計の道具としてのテストダブル
  19. ここまでのまとめ ― TDDのこころ • ひとつずつ 少しずつ • 複数を相手にしない • すばやく回す

    • 自分が最初のユーザ • 不安をテストに • 祈るのではダメ • 命綱を編む
  20. テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数

    9 6 5-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
  21. TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical

    Studies" Simo Makinen and Jurgen Munch • 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究 の結論を整理した • TDDは欠陥の作り込み(introduced defects)を減らし、メンテナンス しやすいコードを産む • TDDで実装されたコードは、部分的に、サイズが小さく、複雑度が低 い場合がある • メンテナンスがしやすくなるものの、初期開発では時間がかかる
  22. TDDの効果(言い訳編) • テストを自動化できます! • 品質が良くなります! • テストがドキュメントの代わりになります! • 新しい人もすぐキャッチアップできます! •

    メンバーが抜けても大丈夫です! • 修正してもデグレません! • (手で)テストしなくてすみます! • 変更コストが下がります! ※用法、用量を守って安全に使いましょう
  23. • テストを自動化できます! • 品質が良くなります! • テストがドキュメントの代わりになります! • 新しい人もすぐキャッチアップできます! • メンバーが抜けても大丈夫です!

    • 修正してもデグレません! • (手で)テストしなくてすみます! • 変更コストが下がります! ※用法、用量を守って安全に使いましょう TDDの効果(言い訳編) 実践し実績で示す ・自分たちが ・自分の環境・状況で ・効果を出せること
  24. 自動販売機(設計進化重視版) お題1. ボタンを押すとコーラが出る • ボタンを押すとコーラが出ます。 お題2. お金を払う • 100円コインを投入してからボタンを押すとコーラが出ます。 •

    100円コイン以外は投入できません。 お題3. ウーロン茶追加 • 押したボタンに応じてコーラかウーロン茶が出ます。 • 他の飲み物も追加してみましょう。 お題4… 続く
  25. ペアプロのプロトコル はじめに 1. あいさつしましょう 2. ゴールとやることを決めましょう 1. TODOリストを書く 3. 役割を確認しましょう

    ペア作業中 • ドライバーがコードを書く • なにをしているか、常に共有し続ける • タスクはひとつずつ片付けて、確認する • どんどん役割を交代する 区切りで • やったことを見直しましょう • 方針を見直さなくていいか、確認しましょう • TODOリストの見直しと更新
  26. スーパーの支払金額 スーパーで買い物したときの支払金額を計算する 以下の商品リストがあるとする。先頭の数字は商品番号。 1. りんご 100円 2. みかん 40円 3.

    ぶどう 150円 4. のり弁 350円 5. しゃけ弁 400円 6. タバコ 420円 7. メンソールタバコ 440円 8. ライター 100円 9. お茶 80円 10. コーヒー 100円