Tweet
Tweet

Slide 1

Slide 1 text

© - BASE, Inc. X ユニットテストの現場の問題を 原則に⽴ち返って考える PHP Conference Fukuoka #phpconfuk . . - @hgsgtk

Slide 2

Slide 2 text

© - BASE, Inc. . 問題を考えるための基礎となるユニットテストの ⽬的 . 現場の問題の整理‧問題に対する戦略の選択肢 . テスト戦略に対するメリット‧デメリットの評価 このトークが提供すること

Slide 3

Slide 3 text

© - BASE, Inc. 判断の「材料」 このトークが提供すること

Slide 4

Slide 4 text

© - BASE, Inc. このトークが提供しないこと 絶対的な「正解」

Slide 5

Slide 5 text

© - BASE, Inc. お品書き：このトークで取り上げる問題 • 意図が汲み取りにくいユニットテストがあります • 不安定なユニットテストがあります • 変更頻度が⾼いユニットテストがあります

Slide 6

Slide 6 text

© - BASE, Inc. このトークの流れ . 取り上げる現場の問題 . ユニットテストの⽬的 . 現場の問題の整理と評価 . まとめ . 参考‧引⽤資料

Slide 7

Slide 7 text

© - BASE, Inc. : @hgsgtk ⾃⼰紹介 東⼝ 和暉 ( Higashiguchi Kazuki ) Backend Engineer (Go, PHP, Python etc) BASE BANK, Inc / Dev Division

Slide 8

Slide 8 text

https://speakerdeck.com/hgsgtk

Slide 9

Slide 9 text

© - BASE, Inc. このトークの流れ .取り上げる現場の問題 . ユニットテストの⽬的 . 現場の問題の整理と評価 . まとめ . 参考‧引⽤資料

Slide 10

Slide 10 text

© - BASE, Inc. お品書き：このトークで取り上げる問題 • 意図が汲み取りにくいユニットテストがあります • 不安定なユニットテストがあります • 変更頻度が⾼いユニットテストがあります

Slide 11

Slide 11 text

© - BASE, Inc. このトークでの問題整理フォーマット 現場でのユニットテストの問題 問題 障害 戦略 その課題の難しさ‧取り組みを妨げる障害 障害に対してどのような戦略‧戦術を⽤いるか 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する

Slide 12

Slide 12 text

© - BASE, Inc. 問題に対する複数の障害を考えていきます 現場でのユニットテストの問題 問題 障害 戦略 判断 評価

Slide 13

Slide 13 text

© - BASE, Inc. このトークの流れ . 取り上げる現場の問題 .ユニットテストの⽬的 . 現場の問題の整理と評価 . まとめ . 参考‧引⽤資料

Slide 14

Slide 14 text

© - BASE, Inc. 我々を取り巻く様々なテスト • 受け⼊れテスト • 機能テスト • 統合テスト • ユニットテスト • 負荷テスト • コード品質テスト • etc

Slide 15

Slide 15 text

© - BASE, Inc. ユニットテストとは • プログラムを構成する⽐較的⼩さな単位（ユニッ ト）が個々の機能を正しく果たしているかどうか を検証する • 実⾏⼿段として、⼿動によるテスト‧⾃動化テス トが存在する • このトークでは、⾃動化テストを取り上げる

Slide 16

Slide 16 text

© - BASE, Inc. なぜユニットテストを書くのか • ⽋陥混⼊の阻⽌、バグを防ぎたい？ • テストによるドキュメンテーション？ • 設計改善の指標？

Slide 17

Slide 17 text

© - BASE, Inc. このトークで定義する⽬的 コスト削減

Slide 18

Slide 18 text

© - BASE, Inc. コスト削減の指標 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ VS

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

© - BASE, Inc. コスト削減の指標 Ϣχοτςετ ʹΑΔ ίετ࡟ݮ Ϣχοτςετ ͷ ࡞੒ɾҡ࣋ίετ >

Slide 21

Slide 21 text

© - BASE, Inc. 詳しくはこちらの資料を https://speakerdeck.com/hgsgtk/practices-to-write-better-unit-test

Slide 22

Slide 22 text

© - BASE, Inc. まとめ • ユニットテストの⽬的をコスト削減とおく • ユニットテストによるコスト削減が、ユニットテスト による発⽣コストを上回る状態を維持する

Slide 23

Slide 23 text

© - BASE, Inc. （CM）BASEとは ネットショップ作成サービス 「BASE」 ショッピングアプリ 「BASE」 価値の交換をよりシンプルにし、 世界中の⼈々が最適な経済活動を⾏えるようにする。 MISSION

Slide 24

Slide 24 text

© - BASE, Inc.

Slide 25

Slide 25 text

© - BASE, Inc. このトークの流れ . 取り上げる現場の問題 . ユニットテストの⽬的 .現場の問題の整理と評価 . まとめ . 参考‧引⽤資料

Slide 26

Slide 26 text

© - BASE, Inc. お品書き：このトークで取り上げる問題 • 意図が汲み取りにくいユニットテストがあります • 不安定なユニットテストがあります • 変更頻度が⾼いユニットテストがあります

Slide 27

Slide 27 text

© - BASE, Inc. お品書き：このトークで取り上げる問題 • 意図が汲み取りにくいユニットテストがあります • 不安定なユニットテストがあります • 変更頻度が⾼いユニットテストがあります

Slide 28

Slide 28 text

© - BASE, Inc. 意図が汲み取りにくいユニットテストがあります 意図が汲み取りにくいユニットテストがあります 問題 障害 • 意図が不明瞭なテストコード

Slide 29

Slide 29 text

© - BASE, Inc. 意図が不明瞭なテストコード

Slide 30

Slide 30 text

© - BASE, Inc. 意図が不明瞭なテストコード 「1がtrueで2がfalseね、ワカラナイ」

Slide 31

Slide 31 text

© - BASE, Inc. 意図が汲み取りにくいユニットテストがあります 意図が汲み取りにくいユニットテストがあります 問題 障害 戦略 意図が不明瞭なテストコード “Communicate Intent”

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

© - BASE, Inc. “Obscure Test”（曖昧なテスト） • ひと⽬で理解することが難しいテスト • ドキュメントとしての効果が減り、メンテナンス コストの⾼いテストにつながる Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 15. Code Smells

Slide 34

Slide 34 text

© - BASE, Inc. 戦略を使って改善する例

Slide 35

Slide 35 text

© - BASE, Inc. 戦略を使って改善する例 「2は禁⽌ユーザーだからfalseなのね」

Slide 36

Slide 36 text

© - BASE, Inc. 意図が汲み取りにくいユニットテストがあります 意図が汲み取りにくいユニットテストがあります 問題 障害 戦略 意図が不明瞭なテストコード “Communicate Intent” 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する

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

© - BASE, Inc. +α 失敗の原因を明瞭に伝える適切なエラーレポート • テストコード⾃体が “Communicate Intent”で あることが重要 • 発想の⼀つとして、Goのユニットテストについて のアイデアを抑える • テスト結果だけで「なぜ失敗したのか」がわかる “適切なエラーレポート”

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

© - BASE, Inc. +α Proper error reportingの例 (Go)

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

© - BASE, Inc. +α 失敗の原因を明瞭に伝える適切なエラーレポート • ⾔語は違えどエラーレポーティングの考え⽅は頭 の⽚隅に意識しておくとよい • PHPUnit\Framework\Assert::assertXxxはメッ セージを渡すことができる • テスト失敗原因が分かりづらいかも知れないと 思ったときに意識すると、メンテナンスコストの 低い費⽤対効果の良いテストコードになりうる

Slide 45

Slide 45 text

© - BASE, Inc. まとめ： 意図が汲み取りにくいユニットテストがあります 意図が汲み取りにくいユニットテストがあります 問題 障害 戦略 意図が不明瞭なテストコード “Communicate Intent” 判断 評価 . ドキュメンテーションコス トの削減 . 既存テスト維持コストの削 減 . 該当なし >

Slide 46

Slide 46 text

© - BASE, Inc. (CM) BASE BANK 銀⾏をかんたんにし、全ての⼈が挑戦できる世の中に MISSION https://thebase.in/yellbank • BASE, Inc の100%⼦会社 • 即座に資⾦調達ができる⾦融サービ ス「YELL BANK（エールバンク）」 を運営

Slide 47

Slide 47 text

© - BASE, Inc. お品書き：このトークで取り上げる問題 • 意図が汲み取りにくいユニットテストがあります • 不安定なユニットテストがあります • 変更頻度が⾼いユニットテストがあります

Slide 48

Slide 48 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 • 実⾏順序で結果が変わるユニットテスト • 相互依存するデータベースフィクスチャ

Slide 49

Slide 49 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 • 実⾏順序で結果が変わるユニットテスト • 相互依存するデータベースフィクスチャ

Slide 50

Slide 50 text

© - BASE, Inc. 実⾏順序で結果が変わるテスト

Slide 51

Slide 51 text

© - BASE, Inc. 実⾏順序で結果が変わるテスト

Slide 52

Slide 52 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 戦略 実⾏順序で結果が変わるユニットテスト “Keep Tests Independent”

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

© - BASE, Inc. 逸脱の常態化（normalization of deviance） “テストスイートへ信頼を失い、「常にこのように 失敗する」と思うようになります。” “間違っているものに慣れすぎて、それを正常で問 題ないと徐々に受け⼊れ始めることがあるという考 え⽅です。” Refs ॻ੶ʰϚΠΫϩαʔϏεΞʔΩςΫνϟʱ / 7ষ ςετ - 7.6 ৴པͰ͖ͳ͍੬ऑͳςετ

Slide 56

Slide 56 text

© - BASE, Inc. 経験上の主な原因：実⾏順序で結果が変わる • テストセットアップ‧実⾏時に⾏ったグローバル な状態変更を後⽚付けできていない • グローバルな状態変更 • グローバル変数の更新 • トランザクション状態 • テスト実⾏時間 • etc

Slide 57

Slide 57 text

© - BASE, Inc. 戦略を使った改善例：tearDown()での後⽚付け https://github.com/cakephp/cakephp/blob/14b1fece73b4786f1f3f23f77c828aa477f5e002/src/TestSuite/TestCase.php#L156

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

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 戦略 実⾏順序で結果が変わるユニットテスト “Keep Tests Independent” 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する

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

© - BASE, Inc. まとめ：不安定なユニットテストがあります > 実⾏順序で結果が変わるユニットテスト 不安定なユニットテストがあります 問題 障害 戦略 実⾏順序で結果が変わるユニットテスト “Keep Tests Independent” 判断 評価 . ⽋陥の早期発⾒による修コ スト削減 . 既存テスト維持コスト削減 . ユニットテストの学習コス ト発⽣ > <

Slide 66

Slide 66 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 • 実⾏順序で結果が変わるユニットテスト • 相互依存するデータベースフィクスチャ

Slide 67

Slide 67 text

© - BASE, Inc. 相互依存するデータベースフィクスチャ

Slide 68

Slide 68 text

© - BASE, Inc. 相互依存するデータベースフィクスチャ 「テストを追加するゾ」

Slide 69

Slide 69 text

© - BASE, Inc. 相互依存するデータベースフィクスチャ 「テストを追加するゾ」

Slide 70

Slide 70 text

© - BASE, Inc. 相互依存するデータベースフィクスチャ 「テストを追加するゾ」

Slide 71

Slide 71 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 戦略 相互依存するデータベースフィクスチャ Minimal Fixture / Standard Fixture

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

© - BASE, Inc. “Shared Fixture” “We reuse the design of the test fixture across the many tests.

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

© - BASE, Inc. “Minimal Fixture” “Use the smallest and simplest fixture possible for each test.” ex. Larval: Factory, Ruby on Rails: FactoryBot

Slide 76

Slide 76 text

© - BASE, Inc. Standard & Minimal Fixture • ２つの戦略を組み合わせて使う

Slide 77

Slide 77 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 戦略 相互依存するデータベースフィクスチャ Minimal Fixture / Standard Fixture 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する

Slide 78

Slide 78 text

© - BASE, Inc. 不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 戦略 相互依存するデータベースフィクスチャ Minimal Fixture / Standard Fixture 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する Minimal Fixture‧Standard Fixture ２つの戦略の⽐較から考える

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

© - BASE, Inc. まとめ：不安定なユニットテストがあります 不安定なユニットテストがあります 問題 障害 戦略 相互依存するデータベースフィクスチャ Minimal Fixture / Standard Fixture 判断 評価 . Minimal Fixtureのメリッ ト/デメリット . Standard Fixtureのメリッ ト/デメリット > <

Slide 89

Slide 89 text

© - BASE, Inc. お品書き：このトークで取り上げる問題 • 意図が汲み取りにくいユニットテストがあります • 不安定なユニットテストがあります • 変更頻度が⾼いユニットテストがあります

Slide 90

Slide 90 text

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 • 内部実装に依存したユニットテスト • Mockが妨げるユニットテスト

Slide 91

Slide 91 text

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 • 内部実装に依存したユニットテスト • Mockが妨げるユニットテスト

Slide 92

Slide 92 text

© - BASE, Inc. 内部実装に依存したユニットテスト

Slide 93

Slide 93 text

© - BASE, Inc. 内部実装に依存したユニットテスト Private methodに対して、 ちょっとしたリファクタリングを⾏ う（外部の振る舞いは変わらない）

Slide 94

Slide 94 text

© - BASE, Inc. ERRORS! Tests: , Assertions: , Errors: . ArgumentCountError: Too few arguments to function Hoge::getUserPoint(), passed and exactly expected

Slide 95

Slide 95 text

© - BASE, Inc. 内部実装に依存したユニットテスト

Slide 96

Slide 96 text

© - BASE, Inc. 内部実装に依存したユニットテスト Private Method “getUserPoint”に対する ユニットテストが失敗していた "ArgumentCountError: Too few arguments to function Hoge::getUserPoint(), passed and exactly expected”

Slide 97

Slide 97 text

© - BASE, Inc. 内部実装に依存したテスト • 内部実装: 公開していない実装情報 • private / protected • 内部実装に依存しすぎるテストは、 “Fragile Test” （壊れやすいテスト）と呼ばれる • 振る舞いを変えない改善に対してもテストが反応 してしまう

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

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 戦略 内部実装に依存したテスト “Use the Front Door First”

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

© - BASE, Inc. “Front Door”を介するための選択肢 . 既存の public インターフェースからテストする . private インタフェースを public に引き上げる

Slide 102

Slide 102 text

© - BASE, Inc. “publicメソッドにすべきかどうかで悩んでしまう 場合、たいていはそのクラスが多くのことを⾏いす ぎており、修正すべきであることを意味していま す。” Refs ॻ੶ʰϨΨγʔίʔυվળΨΠυʱ/ 10.1 ӅΕͨϝιου

Slide 103

Slide 103 text

© - BASE, Inc. 戦略を使って改善する例 「ポイント合計算出」を別クラスに移乗してpublicにする

Slide 104

Slide 104 text

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 戦略 内部実装に依存したテスト “Use the Front Door First” 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する

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

© - BASE, Inc. まとめ：変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 戦略 内部実装に依存したテスト “Use the Front Door First” 判断 評価 . 設計改善によるメンテナン スコスト削減 . 既存テスト維持コスト . ⽋陥の早期発⾒による修正 コスト増加（の可能性） > <

Slide 110

Slide 110 text

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 • 内部実装に依存したユニットテスト • Mockが妨げるユニットテスト

Slide 111

Slide 111 text

© - BASE, Inc. Mockが妨げるユニットテスト

Slide 112

Slide 112 text

© - BASE, Inc. Mockが妨げるユニットテスト 内部の処理を⼀部リファクタリング する（外部の振る舞いは変わらな い）

Slide 113

Slide 113 text

© - BASE, Inc. ERRORS! Tests: , Assertions: , Errors: . Expectation failed for method name is equal to when invoked time(s). Method was expected to be called times, actually called times.

Slide 114

Slide 114 text

© - BASE, Inc. Mockが妨げるユニットテスト

Slide 115

Slide 115 text

© - BASE, Inc. Mockが妨げるユニットテスト • 「顧客がbanされている」というケースでは TripRepository::getByCustomerId()は呼ぶ必要がなくなっ た。 • しかし、ユニットテストは呼び出されることを期待している ため、テストは失敗する

Slide 116

Slide 116 text

© - BASE, Inc. “Mock” を定義するためのxUTPによる語彙整理 Test Double: テスト固有の同等物 Mock: テスト対象に適切に使⽤されているか検証 する Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ / Chapter 23. Test Double Patterns

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

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります 変更頻度が⾼いユニットテストがあります 問題 障害 戦略 Mockが妨げるユニットテスト “的確なエクスペクテーション”

Slide 119

Slide 119 text

© - BASE, Inc. 的確なエクスペクテーション Refs ॻ੶ʰ࣮ફςετۦಈ։ൃʱ / ୈ20ষ ςετͷ੠Λௌ͘ “意図を明確にするためには、スタブとエクスペク テーション‧アサーションをきっちり区別するとよ い。”

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

© - BASE, Inc. 区別するための指標：コマンド/クエリ • クエリは、外の世界を変化させない • 何回呼んでも呼ばなくても構わない • ⇒ アローアンス Refs ॻ੶ʰ࣮ફςετۦಈ։ൃʱ / ୈ20ষ ςετͷ੠Λௌ͘ ΫΤϦʹ͸ΞϩʔΞϯεɺίϚϯυʹ͸ΤΫεϖΫςʔγϣϯ

Slide 122

Slide 122 text

© - BASE, Inc. 戦略を使って改善する

Slide 123

Slide 123 text

© - BASE, Inc. 変更頻度が⾼いユニットテストがあります
 > Mockが妨げるユニットテスト 変更頻度が⾼いユニットテストがあります 問題 障害 戦略 Mockが妨げるユニットテスト “的確なエクスペクテーション” 判断 評価 . 戦略のメリット . を評価する . 戦略のデメリット . を評価する

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

© - BASE, Inc. まとめ：変更頻度が⾼いユニットテストがあります
 > Mockが妨げるユニットテスト 変更頻度が⾼いユニットテストがあります 問題 障害 戦略 Mockが妨げるユニットテスト “的確なエクスペクテーション” 判断 評価 . ドキュメンテーションコス ト削減 . 既存テスト維持コスト削減 . ⽋陥の早期発⾒による修正 コスト削減 > <

Slide 129

Slide 129 text

© - BASE, Inc. このトークの流れ . 取り上げる現場の問題 . ユニットテストの⽬的 . 現場の問題の整理と評価 .まとめ . 参考‧引⽤資料

Slide 130

Slide 130 text

© - BASE, Inc. まとめ • 課題の分析‧それに対する原則‧戦略は多くの⽂ 献で⽰されている • しかし、それらにはメリット‧デメリットがそれ ぞれあり、絶対的な正解はない • 状況に応じてどの選択肢が適切か判断する必要が ある

Slide 131

Slide 131 text

© - BASE, Inc. “やり⽅”を覚える ⇒ “考え⽅”を⾝につ ける

Slide 132

Slide 132 text

© - BASE, Inc. このトークの流れ . 取り上げる現場の問題 . ユニットテストの⽬的 . 現場の問題の整理と評価 . まとめ .参考‧引⽤資料

Slide 133

Slide 133 text

© - BASE, Inc. 今回取り上げなかった「テスト駆動開発」について https://speakerdeck.com/hgsgtk/tesutokaxin-iwojie-jue-surutesutoqu-dong-kai-fa-falseahuroti-at-phpkanhuarensuxian-tai-

Slide 134

Slide 134 text

© - BASE, Inc. 今回取り上げなかった「レガシーコード改善のテスト」 について https://speakerdeck.com/hgsgtk/phpbaziyonatuputojue-ji-ripureisuwozhi-etayunitutotesuto-number-phpcon

Slide 135

Slide 135 text

© - BASE, Inc. 今回取り上げなかった「個⼈としてのテストの始め⽅」 について https://speakerdeck.com/hgsgtk/tesutowoshu-itakotokanaiensiniakatesutowoshu-keruyouninarumateyatutakoto-at-phpkanhuarensuguan-xi-

Slide 136

Slide 136 text

© - BASE, Inc. 参考‧引⽤資料 - トーク内で引⽤した書籍 • 『xUnit Test Patterns: Refactoring Test Code』 • 『テスト駆動開発』 • 『実践テスト駆動開発』 • 『マイクロサービスアーキテクチャ』 • 『レガシーコード改善ガイド』 • 『プログラミング⾔語Go』

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

© - BASE, Inc. ?>