テスト駆動開発入門

by yattom

Slide 1

Slide 1 text

テスト駆動開発入門やっとむ 2018.9.29 TDDBC Tokyo https://is.gd/oWSKeZ

Slide 2

Slide 2 text

安井力 / やっとむ twitter:@yattom https://www.facebook.com/yattom プログラマー Java Python Ruby JavaScript テスト駆動開発アジャイルコーチワークショップ現場導入技術支援ゲームを作って一緒に遊ぶ宝探しアジャイルゲーム、カンバンゲーム、心理的安全性ゲーム

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

テスト駆動開発 / TDD Test Driven Development why?

Slide 5

Slide 5 text

Why Develop?

Slide 6

Slide 6 text

Why Develop? • 実現したいことがあるのに、ソフトウェアがない • 今あるソフトウェアの変更、追加をしたい • プログラムを書くのは楽しい • 難しい

Slide 7

Slide 7 text

Why Test？

Slide 8

Slide 8 text

Why Test？ • 思った通りにできたか知りたい • 問題がないか知りたい • 目的にかなっているか知りたい • 誰かに証明したい • バリデーション vs. ベリフィケーション • チェッキング vs. テスティング

Slide 9

Slide 9 text

Why Test “Driven”？ • フィードバック

Slide 10

Slide 10 text

Development Test

Slide 11

Slide 11 text

テスト駆動開発はふつうの開発

Slide 12

Slide 12 text

実演: Hello World

Slide 13

Slide 13 text

復習 • プロダクトコード (コード) ＝書きたいプログラム • テストコード (テスト) ＝プロダクトコードを書くための自動化テスト

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

「動作するきれいなコード」、ロン・ジェフリーズのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。動作するきれいなコードはあらゆる意味で価値がある。 ─ Kent Beck

Slide 17

Slide 17 text

動作する、きれいなコードへきれい汚い (すぐには)動かない動作する

Slide 18

Slide 18 text

動作する、きれいなコードへきれい汚い (すぐには)動かない動作する二つの道がある

Slide 19

Slide 19 text

TDDでサイクルにするきれい汚い (すぐには)動かない動作する

Slide 20

Slide 20 text

きれい汚い (すぐには)動かない動作する Green Refactoring TDDと黄金の回転

Slide 21

Slide 21 text

TDDのサイクル 1. 次の目標を考える 2. その目標を示すテストを書く 3. そのテストを実行して失敗させる(Red) 4. 目的のコードを書く 5. 2で書いたテストを成功させる(Green) 6. テストが通るままでリファクタリングをおこなう(Refactor) 7. １〜6を繰り返す

Slide 22

Slide 22 text

実演: 計算機

Slide 23

Slide 23 text

計算機の仕様 • 足し算ができる • [x] 引き算ができる • 掛け算ができる • [x] 割り算ができる • [x] 計算できないときはエラーにする

Slide 24

Slide 24 text

復習 • 小さなステップで進める • TODOリストを作る • ユーザーの視点から設計を考える • 仮実装(Fake It) → 三角測量(Triangulation) • リファクタリングをする

Slide 25

Slide 25 text

TODOリストとテスト • 大きな仕様を細かく分割する • 1つ1つのテストを、TODOを達成した証明にする • TODOリストは随時追加・変更・並び替えする • 作りながら仕様がより明確・詳細に理解されていく • 仕様(specification)とは詳細で明確(specific)なもの

Slide 26

Slide 26 text

プログラムは「込み入った領域」で解く分割統治

Slide 27

Slide 27 text

テスト駆動開発はふつう？テスト駆動開発の特徴 • サイクルがとっても早い・短い • テストのほうを先に書く(「テストファースト」) • 必ずテストを書く以上を絶対視する原理主義者もいる多くの人は状況に応じて使い分ける

Slide 28

Slide 28 text

Uncle Bob said … 「クズコードを書くのはもうやめだ」「顧客のため最高のコードを書く」「上司のため最高のテストを書く」「チームのためすべてテストを書く」「上達するため練習を積む」 Software Craftsmanship: What it's all about.

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

TDDは開発手法あるある: 「あ、きみテスト駆動開発やったことあるの？じゃあテスト書けるね！」 • テスト手法ではない！ • プロダクションコードを書くために、テストコードも書く • 他の手法と組み合わせて使える

Slide 31

Slide 31 text

アジャイルテスト高品質を追求するアジャイルチームにおけるテストの視点増田聡 Developer Summit 2010 http://www.slideshare.net/satoshimasuda/ss-3241717

Slide 32

Slide 32 text

余談: TDDのテストはテストじゃない…？ • TDD＝開発手法≠テスト手法 • でもテスト書いてるじゃんね • 単純な事実: TDDで書いたテストは必要なテストすべてを網羅しない可能性がある (網羅したかったら網羅するように書かないといけない) https://www.slideshare.net/goyoki/votddtdd-tdd-on-live

Slide 33

Slide 33 text

• Fast • Independent • Repeatable • Self- Validating • Timely

Slide 34

Slide 34 text

• 高速である • 独立している • 再現性がある • 自己検証可能 • 適時性がある

Slide 35

Slide 35 text

ここまでのまとめ ― TDDとは？ • プロダクトコードとテストコードを並行して書く • 動くか確認しながら進める、ふつうの開発 • TDDのサイクル = レッド・グリーン・リファクタリング • TODOリスト • TDDのテストと品質のテスト • F.I.R.S.T.

Slide 36

Slide 36 text

Why TDD? ― TDDが解決する問題 • テストがない • テストを書かない • ユーザー視点が欠ける • 最善の解を探せない • チーム内でやり方がバラバラ • 機能変更や追加が大変 • 引き継ぎができない

Slide 37

Slide 37 text

Why TDD? ― TDDの効果 • テストがある • テストが書ける • ユーザー視点を持てる • 試行錯誤を通じて最善の設計に近づける • チームのレベルが上がる • 機能変更や追加が容易になる • 意図を残せる

Slide 38

Slide 38 text

Why TDD? ― 人間の問題プユププ利用者の視点を持つ作業分担して協力する

Slide 39

Slide 39 text

Why TDD? ― 人間の問題プユププス使い方を把握する

Slide 40

Slide 40 text

Why TDD? ― 人間の問題プユププ若他の人に理解してもらう

Slide 41

Slide 41 text

Why TDD? ― 人間の問題プユププ他の人に理解してもらう使い方を把握する利用者の視点を持つ作業分担して協力する動作するきれいなコード

Slide 42

Slide 42 text

余談 ― 結合の問題プユププ結合してテストする

Slide 43

Slide 43 text

余談 ― 結合の問題 • テストレベル • ユニット ≒ 自分1人の仕事をテストする • 結合 ≒ 2人以上の仕事を組み合わせてテストする • システム ≒ 実際に使うユーザーの観点でテストする

Slide 44

Slide 44 text

Why TDD? ― 変更容易性の問題 ←プロダクトの死

Slide 45

Slide 45 text

Why TDD? ― 変更容易性の問題 • 設計が複雑化する • ドキュメントが陳腐化する • 全体を把握しきれなくなる • どこを直せばいいか自信がなくなる • 全体を理解していないので、つぎはぎで直す • 直した場所と関係なさそうなところが壊れる • ますます設計が複雑化する

Slide 46

Slide 46 text

Why TDD? ― テストを残す • 将来たくさん変更するなら、毎回テストも必要 • 大規模なプログラムでは、変更の影響範囲把握が難しい → テストは毎回、すべてやりたい回帰テスト • 質問: 将来に渡り、同じテストを100回やるとします手でやるのと、自動テストにするのと、どっちが好き？

Slide 47

Slide 47 text

Why TDD? ― 不安を取り除く • 動くか不安 → テストする • 異常な入力でも平気だろうか → テストする • 動かしたら遅いかも → テストする • 新しい機能は、元からある機能と不整合しないかな？ → テストする • このライブラリどう使うんだろう → テストする • 変なコードだけどどんな結果になるのかな → テストする • こう動くと思うんだけど → テストする • こう書けばいいのかな → テストする • 面倒くさいしこれでいいや → テストする • ねむいつかれたかえりたい → テストする

Slide 48

Slide 48 text

命綱を編む

Slide 49

Slide 49 text

Why TDD? ― 楽しい！「書いたプログラムはちゃんと動くだろうか？」不安「ほらちゃんと動くわーおれすごいわー」楽しい

Slide 50

Slide 50 text

ここまでのまとめ ― Why TDD? • 人間の問題 • 変更容易性の問題 • テストの自動化と回帰テスト • 不安に立ち向かう • 命綱を編む

Slide 51

Slide 51 text

実演: 素因数分解

Slide 52

Slide 52 text

素因数分解の分解 • [ ] 1を素因数分解すると→1 • [ ] 2を素因数分解すると→2 • [ ] 6を素因数分解すると→2, 3 • 3を素因数分解すると→3

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

復習 • テストファースト • 自分にとって不安がないように分割する • 分割した結果はTODOリストに残しておく • テストの中にロジックを書いて、後からコードに移してもよい

Slide 55

Slide 55 text

リファクタリング • リファクタリング… きれいなコードを維持するための作業動作するきれいなコード

Slide 56

Slide 56 text

きれい汚い (すぐには)動かない動作する Green Refactoring TDDと黄金の回転動作するきれいなコード

Slide 57

Slide 57 text

きれいを保つ http://www.flickr.com/photos/adwriter/226233780/

Slide 58

Slide 58 text

リファクタリングの対象 • コードをきれいにする • メソッド名、変数名 • インデント • コメント • 設計も見直す • プロダクトコードもテストコードも見直す • 常にやり続ける • 「動くコード」を保証するテストが前提大

Slide 59

Slide 59 text

わたし「きれい」？ http://pompom0809.hatenablog.com/entry/2016/10/24/205946

Slide 60

Slide 60 text

わたし「きれい」？ ○ きれいな部屋、きれいな机、きれいな作業スペース ×きれいな花、きれいな色、きれいな風景 • 感覚ではなく、客観的なもの • 美醜ではなく、効率や安全に関わるもの • 「動作するもっともシンプルなコード」 • 「もっともシンプル」に到達するには試行錯誤が必要 • きれい、シンプルの基準は、スキルや経験による論理的

Slide 61

Slide 61 text

リファクタリングは可逆変換 • 変数名やメソッド名の変更 • 処理の一部をメソッド化する ⇔ メソッドをインライン化する • 一時変数を導入する ⇔ 変数をインライン化する • データを移動する ⇔ オブジェクトをくくり出す ⇔ メソッドを移動する • 条件記述を分割する ⇔ 条件記述を統合する • その他いろいろリファクタリングを使って「動作するもっともシンプルなコード」を模索する

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

実演: 素因数分解のリファクタリング

Slide 64

Slide 64 text

復習 • 試行錯誤する • リファクタリング前後で見比べて、いい方を選ぶ • ツール(IDE)の機能を活用する

Slide 65

Slide 65 text

TDDは設計手法？ • 設計＝決断 • いくつも考えられる候補から1つ選ぶのが設計 • ドキュメントを書くのが設計ではないよ！ • コードを書く＝大小様々な決断の連続 • 意識せずに決断していることも • リファクタリングは決断を見直して、よりよい設計を見つける機会

Slide 66

Slide 66 text

どの設計が好き？どれがきれい？

Slide 67

Slide 67 text

きれい汚い (すぐには)動かない動作する Green Refactoring きれいに到達する手段試行錯誤改善机上設計理想実験

Slide 68

Slide 68 text

http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html

Slide 69

Slide 69 text

きれいに到達する手段 ― テストダブル依存コンポーネントを置き換え、テスト対象のコードを実行できるさらに、直接アクセスできない箇所を対象にしたアサーションができる • テストダブルの種類 (xUnit Patterns) • スタブ • モック • スパイ • フェイク

Slide 70

Slide 70 text

すでにきれいじゃないときは • 直して祈る保護して変更する • 「シーム(縫い目、接合部)」を見つける • 第6章時間がないのに変更しなければなりません • 第9章このクラスをテストハーネスに入れることができません • 第11章変更する必要がありますが、どのメソッドをテストすればよいのでしょうか？ • 第16章変更できるほど十分に私はコードを理解していません • 第21章同じコードをいたるところで変更しています • 第24章もうウンザリです。何も改善できません

Slide 71

Slide 71 text

ここまでのまとめ ― リファクタリング • リファクタリングできれいを保つ • きれい＝Clean 美醜ではない • TDDサイクルの一部として、常にやる • コードも、テストも、設計もリファクタリングする • 試行錯誤と設計の改善 • 設計の道具としてのテストダブル

Slide 72

Slide 72 text

TDDのこころ

Slide 73

Slide 73 text

TDDのこころテストに出ます！コードにも出ます！

Slide 74

Slide 74 text

一つずつ少しずつ段を小さく

Slide 75

Slide 75 text

ひとりずつ対処する。複数を相手にしない。

Slide 76

Slide 76 text

すばやくまわす

Slide 77

Slide 77 text

自分が最初のユーザ

Slide 78

Slide 78 text

不安をテストに

Slide 79

Slide 79 text

祈るのではダメ

Slide 80

Slide 80 text

命綱を編む

Slide 81

Slide 81 text

ここまでのまとめ ― TDDのこころ • ひとつずつ少しずつ • 複数を相手にしない • すばやく回す • 自分が最初のユーザ • 不安をテストに • 祈るのではダメ • 命綱を編む

Slide 82

Slide 82 text

テスト駆動開発の効果 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

Slide 83

Slide 83 text

TDDの効果の研究をまとめた研究 "Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies" Simo Makinen and Jurgen Munch • 既存の実証研究を調査し、10の内部・外部品質評価項目で、各研究の結論を整理した • TDDは欠陥の作り込み(introduced defects)を減らし、メンテナンスしやすいコードを産む • TDDで実装されたコードは、部分的に、サイズが小さく、複雑度が低い場合がある • メンテナンスがしやすくなるものの、初期開発では時間がかかる

Slide 84

Slide 84 text

TDDの効果の研究をまとめた研究やっとむ TDD 検索

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

TDDはスキルである http://www.flickr.com/photos/nicohogg/75040212/

Slide 87

Slide 87 text

TDDは練習して上達する http://www.flickr.com/photos/risager/8388040402

Slide 88

Slide 88 text

• テストを自動化できます！ • 品質が良くなります！ • テストがドキュメントの代わりになります！ • 新しい人もすぐキャッチアップできます！ • メンバーが抜けても大丈夫です！ • 修正してもデグレません！ • (手で)テストしなくてすみます！ • 変更コストが下がります！ ※用法、用量を守って安全に使いましょう TDDの効果(言い訳編) 実践し実績で示す・自分たちが・自分の環境・状況で・効果を出せること

Slide 89

Slide 89 text

TDDのテストで「本当に必要なもの」を先に決める

Slide 90

Slide 90 text

https://www.flickr.com/photos/emotakespictures/33245514280/ 行き先を示す道しるべ

Slide 91

Slide 91 text

足下を照らす明かり https://www.flickr.com/photos/menschmaschine/19898877294/

Slide 92

Slide 92 text

自分の歩幅で

Slide 93

Slide 93 text

実演: 自動販売機(設計進化重視版) お題1. ボタンを押すとコーラが出る •ボタンを押すとコーラが出ます。

Slide 94

Slide 94 text

実演: 自動販売機お題2. お金を払う •100円コインを投入してからボタンを押すとコーラが出ます。 •100円コイン以外は投入できません。

Slide 95

Slide 95 text

実演: 自動販売機お題3. ウーロン茶追加 •押したボタンに応じてコーラかウーロン茶が出ます。 •他の飲み物も追加してみましょう。

Slide 96

Slide 96 text

本日のお題自動販売機(設計進化重視版) https://is.gd/uUk8kp

Slide 97

Slide 97 text

自動販売機(設計進化重視版) お題1. ボタンを押すとコーラが出る • ボタンを押すとコーラが出ます。お題2. お金を払う • 100円コインを投入してからボタンを押すとコーラが出ます。 • 100円コイン以外は投入できません。お題3. ウーロン茶追加 • 押したボタンに応じてコーラかウーロン茶が出ます。 • 他の飲み物も追加してみましょう。お題4… 続く

Slide 98

Slide 98 text

ペアプロのプロトコルはじめに 1. あいさつしましょう 2. ゴールとやることを決めましょう 1. TODOリストを書く 3. 役割を確認しましょうペア作業中 • ドライバーがコードを書く • なにをしているか、常に共有し続ける • タスクはひとつずつ片付けて、確認する • どんどん役割を交代する区切りで • やったことを見直しましょう • 方針を見直さなくていいか、確認しましょう • TODOリストの見直しと更新

Slide 99

Slide 99 text

本日のお題スーパーの支払金額 https://is.gd/lsXS1B

Slide 100

Slide 100 text

スーパーの支払金額スーパーで買い物したときの支払金額を計算する以下の商品リストがあるとする。先頭の数字は商品番号。 1. りんご 100円 2. みかん 40円 3. ぶどう 150円 4. のり弁 350円 5. しゃけ弁 400円 6. タバコ 420円 7. メンソールタバコ 440円 8. ライター 100円 9. お茶 80円 10. コーヒー 100円

Slide 101

Slide 101 text

スーパーの支払金額以下の順番で、仕様を追加・実装していく。お題1 合計金額商品番号と個数を複数組、引数として受け取り、合計金額を計算する関数を書いてみよう。ヒント: 複数のものを受け取るために、配列やリストで一括で渡す方法がある。あるいは、1つ渡す関数を何回も呼び出して、最後に合計金額を計算する関数を呼び出すという形式もある。両方のアプローチをTDDで実装し見比べて、どちらが良いか判断してみよう。いきなり書くのが難しかったら、以下の補題をやってみるとよい。補題1 商品番号を渡すと、1個あたりの金額を計算する関数を書いてみよう。補題2 商品番号を複数渡すと、個数1個として金額を合計する関数を書いてみよう。

Slide 102

Slide 102 text

スーパーの支払金額お題2 消費税商品リストの金額は外税なので、合計金額に消費税8％を足して、支払金額を返すようにしよう。お題3 タバコの消費税タバコの価格には消費税が含まれているので(内税)、消費税の計算からタバコは除かないといけない。

Slide 103

Slide 103 text

スーパーの支払金額お題4 割引リンゴは1個100円だが、3つ買うと280円になる。お題5 おまけなんでも、同じものを10個買うと、1個おまけでもらえる。11個で10個ぶんの金額（12個で11 個分、20個で19個分、22個で20個分、...)という形で実現しよう。

Slide 104

Slide 104 text

スーパーの支払金額お題6 おまけのライタータバコを1カートン(10個)買うと、ライターがおまけでもらえる。引数にライターがあったら無料になるというふうに実現しよう。お題7 お弁当弁当類と飲み物(お茶とコーヒー)をいっしょに買うと、20円引きになる。

Slide 105

Slide 105 text

スーパーの支払金額お題8 サービスしすぎないお題4～7のようなサービスは、同じ商品については重複しない。一番安くなるものをひとつだけ適用する。お題9 タイムセールお弁当は20時を過ぎると半額になる。お題10 タイムセールとサービスお弁当のタイムセールは、他のサービスと重複してよい。

Slide 106

Slide 106 text

スーパーの支払金額お題11 コンフィグレーション以上のようなサービス内容を、プログラムと別の設定ファイルなどで自由に変更できるようにしたい。

Slide 107

Slide 107 text

本日のお題整数の区間 http://bit.ly/1hAoTeG

Slide 108

Slide 108 text

本日のお題 DFG(大富豪の手判定) https://is.gd/RIC2HW

Slide 109

Slide 109 text

本日のお題セマンティック・バージョニング https://is.gd/YT5tN0