Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
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 • 2つの戦略を組み合わせて使う
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 2つの戦略の⽐較から考える
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. ?>