ユニットテストの現場の問題を原則に立ち返って考える / think deep unit test practical problem

by Kazuki Higashiguchi

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

https://speakerdeck.com/hgsgtk

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ ユニットテストの両⾯のコスト Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© - BASE, Inc. “Communicate Intent”（意図を伝える） • テストをメンテナンスする開発者が、理解しやすくメンテナンスしやすいテストにすること • xUTP(※ )の⾃動テストの原則の⼀つ • 理解が難しいコードは、“Obscure Test”と表現される ※1 ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 5. Principles of Test Automation / ࣗಈςετͷ໨తɾݪଇΛମܥతʹ੔ཧͨ͠ॻ੶

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Communicate Intent”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ •υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • 作成者の「意図」が伝わることで、テスト対象コードのドキュメンテーションとしての価値が⾼まる

Slide 38

Slide 38 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ •طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Communicate Intent”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ •υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • テストの可読性が向上することで、メンテナンス性の良いコードになる。

Slide 39

Slide 39 text

© - BASE, Inc. “Communicate Intent”の判断 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ > • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ •υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • ৽نςετ࡞੒ίετൃੜ •طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© - BASE, Inc. +α Go FAQ: Why does Go not have assertions? Go⾔語では、アサートを提供していません。アサートが便利である点は疑う余地はありませんが、我々の経験的には、プログラマはアサートを、適切なエラーハンドリングとエラーレポートを考慮せずに済ますためのツールとして使っています。（※ 原⽂私訳） Refs: https://golang.org/doc/faq#assertions

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© - BASE, Inc. +α Proper error reportingの例 (Go) === RUN TestInStatusList --- FAIL: TestInStatusList ( . s) sample_test.go: : InStatusList(deleted) = false, want true FAIL 直接的かつ適切な内容をレポートに込める ex. “f(x) = y, want z”という⼀つの形式 Refs ॻ੶ʰϓϩάϥϛϯάݴޠGoʱ / ୈ11ষ ςετ

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© - BASE, Inc. “Keep Tests Independent”（テストを独⽴させる） • テストが相互依存‧順序依存する場合、”独⽴性” がない状態 • 独⽴していないテストは、 “Erratic Test”（不安定なテスト）と呼ばれる Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 5. Principles of Test Automation

Slide 54

Slide 54 text

© - BASE, Inc. “Erratic Test”（不安定なテスト） • “sometimes they pass and sometimes they fail” • 不安定な状態を続けると、他の原因での失敗を⾒逃してしまうリスクが有る • この問題のトラブルシューティングは難しい Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 15. Code Smells

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

© - BASE, Inc. 戦略を使った改善例：tearDown()での後⽚付け https://github.com/cakephp/cakephp/blob/ 14b1fece73b4786f1f3f23f77c828aa477f5e002/src/TestSuite/TestCase.php#L156 この例は、CakePHP .x⾃⾝がやっているtearDown() プロジェクトの経験上、忘れがち‧問題になりがちな後⽚付け忘れがあれば、 super classで毎回tearDownしておく選択肢も

Slide 59

Slide 59 text

Slide 60

Slide 60 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Keep Tests Independent”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ •ܽؕͷૣظൃݟʹΑΔ मਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • “Erratic Test”（不安定なテスト）回避効果 • 別の⽋陥‧問題を⾒逃してしまうリストの低下

Slide 61

Slide 61 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ •طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ •ܽؕͷૣظൃݟʹΑΔ मਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • “Erratic Test”（不安定なテスト）回避効果 • トラブルシューティングの難しいコストの掛かる現象の回避 “Keep Tests Independent”メリット

Slide 62

Slide 62 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ •طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ •Ϣχοτςετͷ ֶशίετൃੜ “Keep Tests Independent”のデメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ •ܽؕͷૣظൃݟʹΑΔ मਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • Super classで共通のtearDown をしていても、個別で必要だった⽚付けの⾒逃しや⽚付け忘れはありうる • その際のErratic Testの原因特定のために、「何を⽚付けてくれているか」知る必要がある • クラスの層ができるので、ある種の「プロジェクトの仕様」を学習する機会が発⽣する

Slide 63

Slide 63 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ •طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ •Ϣχοτςετͷ ֶशίετൃੜ “Keep Tests Independent”のコスト評価 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ •ܽؕͷૣظൃݟʹΑΔ मਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ

Slide 64

Slide 64 text

© - BASE, Inc. +α テストの実⾏順序を指定する必要がある場合 • TestMethodA -> Bと順序を指定したいケースもありうる • PHPUnitでは、@depends アノテーション等でテストの依存関係を明⽰することも可能 Refs https://phpunit.de/manual/6.5/en/writing-tests-for- phpunit.html#writing-tests-for-phpunit.test-dependencies

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

© - BASE, Inc. “Standard Fixture” • “We reuse the design of the test fixture across the many tests. • 複数のテストケースでフィクスチャレコード定義を共有する戦略 Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 18. Test Strategy Patterns

Slide 73

Slide 73 text

Slide 74

Slide 74 text

© - BASE, Inc. “Minimal Fixture” • “Use the smallest and simplest fixture possible for each test.” • テストケースごとにフィクスチャレコード定義を⽤意する戦略 Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 18. Test Strategy Patterns

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

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Standard Fixture”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • ⼀つの定義で済むのでフィクスチャの作成コストが削減 • ex. ユーザー情報のレコード準備

Slide 80

Slide 80 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Standard Fixture”のデメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • 複数テストケースで共有する分、相互依存する • テスト間の独⽴性が低下 • 影響範囲を考慮に⼊れたテスト作成が必要になる

Slide 81

Slide 81 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Standard Fixture”のデメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • フィクスチャレコードが⼤きくなりがちなので、テスト準備に時間がかかる • テストの実⾏速度が低下する

Slide 82

Slide 82 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Standard Fixture”の評価 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ

Slide 83

Slide 83 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Minimal Fixture”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • テストケースごとの影響範囲なので、最⼩限のフィクスチャレコードを⽤意すればいい • エッジケースのテストパターンを作りやすい • ex. 「利⽤禁⽌ユーザー」

Slide 84

Slide 84 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Minimal Fixture”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • 既存テストコードが依存するフィクスチャの影響範囲が明確 • 影響範囲が理解しやすい分、メンテナンスもしやすいテストフィクスチャになる

Slide 85

Slide 85 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Minimal Fixture”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • テストレコードが最⼩限なので、テスト実⾏速度が（少し）早い

Slide 86

Slide 86 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Minimal Fixture”のデメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • “Standard Fixture”のメリットでもあるテストレコードの再利⽤

Slide 87

Slide 87 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Minimal Fixture”の評価 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

© - BASE, Inc. “Fragile Test” （壊れやすいテスト） • 修正した箇所と無関係なはずのテストが失敗しはじめる。 • いくつかの原因のうち、 “Overspecified Software” という状況となっている • テストコードで、テスト対象の振る舞いを過剰に検証している。 Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 16. Behavior Smells

Slide 99

Slide 99 text

Slide 100

Slide 100 text

© - BASE, Inc. “Use the Front Door First”（最初に正⾯⽞関を使う） • 外部から利⽤することを期待する public インタフェースと、内部のみからが期待される private インターフェース • テスト対象とは可能な限り、Front Door （public interface）を介した対話をする Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 5. Principles of Test Automation

Slide 101

Slide 101 text

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Use the Front Door First”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔ ϝϯςφϯείετ࡟ݮ • クラスの責務の⾒直しによる設計改善 • メンテナンス性の⾼い動作コードへ

Slide 106

Slide 106 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Use the Front Door First”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔ ϝϯςφϯείετ࡟ݮ • 動作コードの変更に対する変更頻度の減少

Slide 107

Slide 107 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Use the Front Door First”のデメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔ ϝϯςφϯείετ࡟ݮ • テスト対象の内部処理は “ブラックボックス” として扱いテストしすぎない • （外側から⾒た振る舞いを検証する） • 内部の private に複雑なロジックが詰め込まれている場合、振る舞い保証が不⼗分な可能性も。

Slide 108

Slide 108 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “Use the Front Door First”の評価 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔ ϝϯςφϯείετ࡟ݮ

Slide 109

Slide 109 text

Slide 110

Slide 110 text

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Slide 116

Slide 116 text

Slide 117

Slide 117 text

© - BASE, Inc. このトーク内での “Mock” は「広義のMock Object」 Refs ॻ੶ʰςετۦಈ։ൃʱ / ෇࿥C Ϣχοτςετपลͷ஌ࣝͷ੔ཧͱTDD֦ுͷࢼΈ • xUTPの語彙整理により、「広義のMock Object」‧「狭義のMock Object」を分けて議論できるようになった • このトークでの “Mock” もTest Doubleの範囲をざっくりと含める「広義のMock Object」とする

Slide 118

Slide 118 text

Slide 119

Slide 119 text

Slide 120

Slide 120 text

© - BASE, Inc. 区別するための指標：コマンド/クエリ Refs ॻ੶ʰ࣮ફςετۦಈ։ൃʱ / ୈ20ষ ςετͷ੠Λௌ͘ ΫΤϦʹ͸ΞϩʔΞϯεɺίϚϯυʹ͸ΤΫεϖΫςʔγϣϯ • コマンドとは、副作⽤を伴うことのある呼び出し • オブジェクトの外の世界を変化させる • ex. DBのレコード保存‧状態変化 • 複数回実⾏した場合、システム状態は違ったものになる => エクスペクテーション

Slide 121

Slide 121 text

Slide 122

Slide 122 text

Slide 123

Slide 123 text

Slide 124

Slide 124 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “的確なエクスペクテーション”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • テストコードのモックオブジェクトが適切にコントロールされる • 対象オブジェクトが他オブジェクトとどう協調するかがテストによって⽰される

Slide 125

Slide 125 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “的確なエクスペクテーション”のメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • 動作コードの変更に対する変更頻度の減少

Slide 126

Slide 126 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “的確なエクスペクテーション”のデメリット Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔ मਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ • すべてエクスペクテーションにすると、過剰ではあるがテスト対象オブジェクトの内部処理が”より”テストされる。

Slide 127

Slide 127 text

© - BASE, Inc. • ৽نςετ࡞੒ίετൃੜ • طଘςετҡ࣋ίετൃੜ • ςετ࣮ߦ࣌ؒͷ଴ͪίετൃੜ • ࣗಈςετͷͨΊͷCIҡ࣋ίετൃੜ • Ϣχοτςετͷֶशίετൃੜ “的確なエクスペクテーション”の評価 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS • खಈϢχοτςετͷίετ࡟ݮ • ܽؕͷૣظൃݟʹΑΔ मਖ਼ίετ࡟ݮ • υΩϡϝϯςʔγϣϯίετ࡟ݮ • σόοάίετ࡟ݮ • ઃܭվળʹΑΔϝϯςφϯείετ࡟ݮ

Slide 128

Slide 128 text

Slide 129

Slide 129 text

Slide 130

Slide 130 text

Slide 131

Slide 131 text

Slide 132

Slide 132 text

Slide 133

Slide 133 text

Slide 134

Slide 134 text

Slide 135

Slide 135 text

Slide 136

Slide 136 text

Slide 137

Slide 137 text

© - BASE, Inc. 参考‧引⽤資料 - トーク構築に寄与した書籍 • 『オブジェクト指向設計実践ガイド ~Rubyでわかる進化しつづける柔軟なアプリケーションの育て⽅』 • 『ソフトウェア‧テストの技法第2版』 • 『プログラマが知るべき97のこと』 • 『リファクタリング既存のコードを安全に改善する』 • 『Clean Code アジャイルソフトウェア達⼈の技』 • 『初めての⾃動テスト』 • 『Succeeding with Agile: Software Development Using Scrum』 • 『エキスパートPythonプログラミング改訂2版』

Slide 138

Slide 138 text