#phperkaigi 2019での発表資料です。 応用編は https://speakerdeck.com/hgsgtk/think-deep-unit-test-practical-problem にて
© - BASE, Inc.「質」のいいユニットテストを書くためのプラクティス. . #phperkaigi - @hgsgtk
View Slide
© - BASE, Inc.このトークの全体図
© - BASE, Inc.このトークの⽬標「初級者」から「中級者」へ
© - BASE, Inc.想定する「初級者」• ユニットテストフレームワークの⽂法がわかる• ⼀通りユニットテストを書いた• どういうテストが良いかわからない
© - BASE, Inc.ユニットテストについて話すこと考え⽅と実践 - 「How Testing?」⽬的 - 「Why Testing?」まとめ - 「That’s why Testing」
© - BASE, Inc.⾃⼰紹介東⼝和暉 （KazukiHigashiguchi）Twitter / GitHub : @hgsgtkサーバーサイドエンジニアBASE BANK, Inc. / Dev Division
© - BASE, Inc.「費⽤対効果の⾼い」このトークでの「質」 の定義
費⽤対効果？🤔
我々はなぜユニットテストを書くのか？
© - BASE, Inc.なぜユニットテストを書くのか• 品質向上、バグを防ぎたい？• テストによるドキュメンテーション？• 設計改善の指標？
© - BASE, Inc.根本的な理由はコスト削減
© - BASE, Inc.コスト削減の指標ϢχοτςετʹΑΔίετݮϢχοτςετͷ࡞ɾҡ࣋ίετVS
© - BASE, Inc.ユニットテストによるコスト削減⼿動ユニットテストのコストドキュメンテーションコスト設計改善によるメンテナンスコスト⽋陥の早期発⾒による修正コストデバッグコスト
© - BASE, Inc.ユニットテストの作成‧維持コスト新規テスト作成コストテスト実⾏時間の待ちコスト既存テスト維持コスト⾃動テストのためのCI維持コストユニットテストの学習コスト
© - BASE, Inc.コスト削減の指標ϢχοτςετʹΑΔίετݮϢχοτςετͷ࡞ɾҡ࣋ίετVS• खಈϢχοτςετͷίετ• ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ• υΩϡϝϯςʔγϣϯίετ• σόοάίετ• ઃܭվળʹΑΔϝϯςφϯείετ• ৽نςετ࡞ίετ• طଘςετҡ࣋ίετ• ςετ࣮ߦ࣌ؒͷͪίετ• ࣗಈςετͷͨΊͷCIҡ࣋ίετ• Ϣχοτςετͷֶशίετ
© - BASE, Inc.「テストの経済性」• 『xUnit Test Patterns』より「テストの経済性」• 最初は、⾃動化テストの学習‧実践コストによってコストが嵩む• 徐々に落ち着いてきて、テストによる節約コストも増えてくる• 結果として、コストは相殺されていくref: https://qiita.com/hgsgtk/items/00daa278516d1995dac6
© - BASE, Inc.テストの⾮経済性• 維持コストが⾼いテストがテスト⾃⾝のコストが上げていく• 可読性が悪い• 修正頻度が多い• 修正が難しい• テストによる節約コストも少ない効果の薄いテスト• 結果的にトータルコストが増⼤していくref: https://qiita.com/hgsgtk/items/00daa278516d1995dac6
© - BASE, Inc.コスト削減の指標ϢχοτςετʹΑΔίετݮϢχοτςετͷ࡞ɾҡ࣋ίετ>
© - BASE, Inc.まとめ：⽬的 - 「Why Testing?」• 根本的な⽬的はコスト削減• xUTPの「テストの経済性」• 費⽤対効果の⾼いユニットテストを⽬指す
© - BASE, Inc.まとめ：⽬的 - 「Why Testing?」「⽬的」
ここで⼀旦CM
© - BASE, Inc.BASEのプロダクトについてネットショップ作成サービス「BASE」ショッピングアプリ「BASE」価値の交換をよりシンプルにし、世界中の⼈々が最適な経済活動を⾏えるようにする。MISSION
© - BASE, Inc.
はい
© - BASE, Inc.費⽤対効果の良いテストを書くために、何を意識するべきかユニットテストの「考え⽅」
© - BASE, Inc.ユニットテストの「考え⽅」「考え⽅」
© - BASE, Inc.ユニットテストの「実践」「実践」
意図を伝えるテスト
© - BASE, Inc.意図を伝えるテスト
© - BASE, Inc.意図を伝えるテスト• テストはメンテナンスされていく• 読み⼿にとって理解しやすくメンテナンスしやすいテストへ
© - BASE, Inc.主に期待する効果ϢχοτςετʹΑΔίετݮϢχοτςετͷ࡞ɾҡ࣋ίετVS• खಈϢχοτςετͷίετ• ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ• υΩϡϝϯςʔγϣϯίετ• σόοάίετ• ઃܭվળʹΑΔϝϯςφϯείετ• ৽نςετ࡞ίετ• طଘςετҡ࣋ίετ• ςετ࣮ߦ࣌ؒͷͪίετ• ࣗಈςετͷͨΊͷCIҡ࣋ίετ• Ϣχοτςετͷֶशίετ
© - BASE, Inc.Test as Documentation意図を伝えるテスト
© - BASE, Inc.このメソッドはどういう仕様？public function canUse(int $user_id): bool{$user = $this->User->findById($user_id);if (empty($user)) {return false;}if (!$user->isProhibit()) {return false;}if ($user->status === 7) {return false;}return true;}
© - BASE, Inc.ユニットテストがない場合ΤϯδχΞこのメソッド何をしてくれるんだろう？• 動作コードを読んで理解する• もしあれば、ドキュメント（単体仕様書など）を読む• 実際に動かして理解する• それでもわからない場合は、作成者に聞きに⾏く
© - BASE, Inc.ユニットテストがない場合ΤϯδχΞこのメソッド何をしてくれるんだろう？• 動作コードを読んで理解する• もしあれば、ドキュメント（単体仕様書など）を読む• 実際に動かして理解する• それでもわからない場合は、作成者に聞きに⾏くよくあるケース• 複雑なコードでひと⽬ではわからない• 意図通りなのかわからない
© - BASE, Inc.ユニットテストがない場合ΤϯδχΞこのメソッド何をしてくれるんだろう？• 動作コードを読んで理解する• もしあれば、ドキュメント（単体仕様書など）を読む• 実際に動かして理解する• それでもわからない場合は、作成者に聞きに⾏くよくあるケース• そもそもない• メンテナンスされてなくて古い
© - BASE, Inc.ユニットテストがない場合ΤϯδχΞこのメソッド何をしてくれるんだろう？• 動作コードを読んで理解する• もしあれば、ドキュメント（単体仕様書など）を読む• 実際に動かして理解する• それでもわからない場合は、作成者に聞きに⾏くよくあるケース• その対象だけを動かすのが難しい• 動かすための前準備に時間がかかる• 繰り返し実⾏するのが⼿間
© - BASE, Inc.ユニットテストがない場合ΤϯδχΞこのメソッド何をしてくれるんだろう？• 動作コードを読んで理解する• もしあれば、ドキュメント（単体仕様書など）を読む• 実際に動かして理解する• それでもわからない場合は、作成者に聞きに⾏くよくあるケース• そもそも作成者が現場にいない• 作成者も覚えてない
© - BASE, Inc.ユニットテストがある場合ΤϯδχΞこのメソッド何をしてくれるんだろう？• ユニットテストを読んで理解する• ユニットテストを実⾏して理解する• 動作コードを読んで理解する• 要件を知るためのドキュメントを読む• （それでもわからない場合）作成者に聞きに⾏く
© - BASE, Inc.テストを読んで仕様を理解する/*** @param int $user_id* @param bool $expected** @see StatusChecker::canUse()* @dataProvider dataProvider_canUse*/public function test_canUse(int $user_id, bool $expected){$checker = new StatusChecker();$this->assertSame($expected, $checker->canUser($user_id));}/*** @return array*/public function dataProvider_canUse(): array{return [‘௨ৗϢʔβʔར༻Մೳͱఆ’ => [1, true],‘Ϣʔβʔ͕ଘࡏ͠ͳ͍߹ར༻ෆՄͱఆ’ => [9999, false],‘ېࢭϢʔβʔͷ߹ར༻ෆՄͱఆ’ => [2, false],‘Ϣʔβʔ͕Ϣʔβʔͷ߹ར༻ෆՄͱఆ’ => [3, false],];}
© - BASE, Inc.テストを実⾏して理解する⽅法について
© - BASE, Inc.Simple TestTest as Documentation
© - BASE, Inc.このテストは何をしている？public function testConditional(){$Flight = new EagerFlight();$Flight->setNumber(1);if ($Flight->number === 1) {$this->assertTrue($Flight->cancel());} else if ($Flight->number === 2) {$this->assertTrue($Flight->cancel2());}if ($Flight->airline_code === 'special') {$this->assertSame(2, $Flight->number);}}
© - BASE, Inc.Simple Test• テストは読み書きする上でシンプルであるべき• ⼩さいテスト• １回につき”ひとつのこと”をテストする• 重点を置くべきは、「テストを書くこと」ではなく「テストをすること」
© - BASE, Inc.Name to Convey IntentTest as Documentation
© - BASE, Inc.このテストはどういうパターン？/*** @param int $user_id* @param bool $expected** @see StatusChecker::canUse()* @dataProvider dataProvider_canUse*/public function test_canUse(int $user_id, bool $expected){$checker = new StatusChecker();$this->assertSame($expected, $checker->canUser($user_id));}/*** @return array*/public function dataProvider_canUse(): array{return [[1, true],[9999, false],[2, false],[3, false],];}
© - BASE, Inc.Name to Convey Intent• 意図、期待値を伝えるための命名‧ラベリング• 読み⼿に伝わる “ドキュメント” を⽬指す
© - BASE, Inc.テストを改善する/*** @param int $user_id* @param bool $expected** @see StatusChecker::canUse()* @dataProvider dataProvider_canUse*/public function test_canUse(int $user_id, bool $expected){$checker = new StatusChecker();$this->assertSame($expected, $checker->canUser($user_id));}/*** @return array*/public function dataProvider_canUse(): array{return [‘௨ৗϢʔβʔར༻Մೳͱఆ’ => [1, true],‘Ϣʔβʔ͕ଘࡏ͠ͳ͍߹ར༻ෆՄͱఆ’ => [9999, false],‘ېࢭϢʔβʔͷ߹ར༻ෆՄͱఆ’ => [2, false],‘Ϣʔβʔ͕Ϣʔβʔͷ߹ར༻ෆՄͱఆ’ => [3, false],];}
© - BASE, Inc.振り返り：主に期待する効果ϢχοτςετʹΑΔίετݮϢχοτςετͷ࡞ɾҡ࣋ίετVS• खಈϢχοτςετͷίετ• ܽؕͷૣظൃݟʹΑΔमਖ਼ίετ• υΩϡϝϯςʔγϣϯίετ• σόοάίετ• ઃܭվળʹΑΔϝϯςφϯείετ• ৽نςετ࡞ίετ• طଘςετҡ࣋ίετ• ςετ࣮ߦ࣌ؒͷͪίετ• ࣗಈςετͷͨΊͷCIҡ࣋ίετ• Ϣχοτςετͷֶशίετ
テストを独⽴させる
© - BASE, Inc.テストを独⽴させる
© - BASE, Inc.SUTに対して疎結合テストを独⽴させる
© - BASE, Inc.SUTに対して疎結合
SUT？🤔
© - BASE, Inc.SUT - Sytem Under Test• テストしている対象を⽰す• ユニットテストの場合、テスト対象のクラス‧メソッドなど• 書籍『xUnit Test Patterns: Refactoring TestCode』で登場する⽤語https://www.amazon.co.jp/dp/ /ref=cm_sw_r_tw_dp_U_x_Y kJCb EX F
© - BASE, Inc.SUTとテストクラスの関係性
© - BASE, Inc.SUTとテストクラスの関係性• CartTestクラスはCartクラスに依存している• クラス間の密結合はメンテナンスしていく上で弊害になりうる• テストクラス‧SUT間もそれは同様
© - BASE, Inc.テストがSUTに密結合する弊害• SUTの変更に敏感に反応してテストが落ちる• ex. Private methodの実装変更• SUTの内部実装を変えるたびに、テストを修正する• 壊れやすいテスト• 維持コストを抑えるために疎結合を意識する
© - BASE, Inc.Test Public MethodSUTに対して疎結合
© - BASE, Inc.Test Public Method• SUTをブラックボックスとして⾒る• ブラックボックスの外から⾒える Public Method に対してテストするのが Better• 逆を返すと、Private Methodはテストしない⽅がBetter• ブラックボックスの外から⾒えない
© - BASE, Inc.尺度：Methodの “安定度”• Public Method• 外部から使⽤される想定を持つ• 変更の頻度が少ない、“安定”している• Private Method• 外部から使⽤される想定はない• 責務の “不安定” さ• 変更の頻度が⾼い、 “不安定”
© - BASE, Inc.Do Not Test Private Method• 変更の頻度が⾼い Private Method• → テストの修正の頻度も⾼くなる• →メンテナンスコストの増⼤• Private Methodは、同⼀クラスのPublic Methodによって使⽤される• → Public Testのテストでカバーできる
© - BASE, Inc.IF YOU CAN, Do Not Test Private Method• 現実の “レガシーコード” を⽬の前にするとテストしたいときはある• Private methodを切り出していくのが Better• それも苦しい時には、リファクタリングの障壁をへらすために、テストを書く選択肢もひとつある
© - BASE, Inc.Isolate SUT from othersSUTに対して疎結合
© - BASE, Inc.突然テストが落ちるようになりました、なぜ？public function test_canUse(int $user_id, bool $expected){$search = CloudSearchWrapper::factory();$search->conditions()->keyword(‘test’, ‘title’)->sort(‘list_order asc’);$search->documentBatch($this->addJson());sleep(3);$result = $search->search($search->conditions()->query());}
© - BASE, Inc.Isolate SUT from others• SUTを他のソフトウェア（外部システム）から隔離する• 依存している場合• 外部システムの動作変更‧状態に応じて、テストが突然落ちる• Dependency Injectionなどの技法の活⽤• 依存しているオブジェクトをTest Doubleに置き換える
© - BASE, Inc.テスト間の独⽴テストを独⽴させる
© - BASE, Inc.テスト間の独⽴
© - BASE, Inc.テスト間の独⽴性• テストが相互依存‧順序依存する場合、 “独⽴性”がない状態• “独⽴性” がない弊害• テストが通ったり落ちたりする• 「ローカルでは通るがCIでは通らないことがある」• 不安定なテスト
© - BASE, Inc.順序依存するテスト
© - BASE, Inc.Depend in Fixture properlyテスト間の独⽴
© - BASE, Inc.Depend in Fixture properly• データベースを⽤いるテストを⾏う場合 Fixture を⽤いる• 全テストケースで共有する 共有されたFixture• 共有しているためテストの追加‧変更に影響を受ける
© - BASE, Inc.共有されたFixtureStandard Fixture
© - BASE, Inc.共有されたFixtureTestE追加のためにFixtureを変更したStandard Fixture
© - BASE, Inc.“Standard Fixture”• “We reuse the design of the test fixtureacross the many tests.• 複数のテストケースでフィクスチャレコード定義を共有する戦略Refs ॻ੶ʰxUnit Test Patterns: Refactoring Test Codeʱ/ Chapter 18. Test Strategy Patterns
© - BASE, Inc.共有されたFixtureのMerit/Demerit• Merit• 共通のマスター系テーブルであれば、⼀回のFixture作成で済む• Demerit• テスト間の独⽴性が損なわれる• エッジケースのテストのやりにくさ
© - BASE, Inc.テストケース専⽤Fixture• テストケースごとに⽤意するFixture (MinimalFixture)• テスト間の独⽴性の向上• ex. Laraval => Factory‧Faker
© - BASE, Inc.共有 & 専⽤ Fixture• ２つの戦略を組み合わせて使うStandard Fixture
© - BASE, Inc.Fixtureに適切に依存する• 全テストで共有することが有益なケース• 基本となるFixtureを定義• ex. 「通常のユーザー」• 使いみちが限定されるエッジケースのテスト• テストケース専⽤Fixtureを⽤意する• ex. 「利⽤禁⽌になったユーザー」
© - BASE, Inc.Tear Down Global Changesテスト間の独⽴
© - BASE, Inc.Tear Down Global Changes• テストがグローバルな状態変化を⽣み出す場合• $_SERVERの書き換え• Session状態の更新• トランザクション• テスト時間 (timecop使⽤の場合など)• 他のテストに影響を及ぼす• テスト‧SUTの状態変化に応じてtearDownしておく
重複を最⼩限に
© - BASE, Inc.重複を最⼩限に
© - BASE, Inc.DRY in Test Code重複を最⼩限に
© - BASE, Inc.DRY in Test Code• DRY (Don’t Repeat Yourself)は、テストコードにおいても同じく意識• テストコードの可読性を上げる• フレームワーク‧カスタムのTest Utilityの活⽤により、より意図を語るテストへ
テスト容易な設計
© - BASE, Inc.テスト容易な設計• テストコードに対する意識‧改善では、費⽤対効果の⾼いテストは実現できない• プロダクションコードのテスタビリティの向上‧改善が必要
© - BASE, Inc.TDDテスト容易な設計
© - BASE, Inc.TDD - Test-Drive Development• プログラム開発⼿法のひとつ• 「動作するきれいなコード」をゴールとする• Red-Green-Refactor のサイクルを回す• 最初に Red にするため、テストファーストで進める
© - BASE, Inc.TDDとテスト容易性• テストファーストによって、テスト容易性が強制される• テストから先に書くため、基本的な⽋陥はテスト実⾏によって気がつくことができる• テスト実⾏だけで実装中のコードをデバッグできる
© - BASE, Inc.TDDによるテスト容易性の強制についてhttps://speakerdeck.com/hgsgtk/tesutokaxin-iwojie-jue-surutesutoqu-dong-kai-fa-falseahuroti-at-phpkanhuarensuxian-tai-2019
© - BASE, Inc.まとめ：考え⽅と実践 - 「How Testing?」• コスト削減を達成するための「考え⽅」• 考え⽅に基づいた「実践」によって、効果を得る
© - BASE, Inc.良いテストを書くのは難しい• 「テストを書く」ことは⽐較的簡単• 費⽤対効果の⾼いテストを書くのは難度が上がる• 費⽤対効果の⾼いテストを⽬指すのは、考えて実践していく必要がある
© - BASE, Inc.費⽤対効果を⾼めるには“テストにコストがかかることの解決⽅法は、テストをやめることではありません。うまくなることです。”Sandi Metz. オブジェクト指向設計実践ガイド 〜Rubyでわかる 進化しつづける柔軟なアプリケーションの育て⽅https://gihyo.jp/book/2016/978-4-7741-8361-9
Enjoy HappyTesting Life 👋
© - BASE, Inc.補⾜：参考書籍『xUnit Test Patterns: Refactoring Test Code』https://www.amazon.co.jp/dp/ /ref=cm_sw_r_tw_dp_U_x_Y kJCb EX F『オブジェクト指向設計実践ガイド 〜Rubyでわかる 進化しつづける柔軟なアプリケーションの育て⽅』https://gihyo.jp/book/ / - - - -
© - BASE, Inc.補⾜：関連資料xUnit Test Patternsから学ぶ12個のユニットテストの原則https://qiita.com/hgsgtk/items/a a d d b dxUnit Test Patternsから学ぶユニットテストの６つの⽬指すべきゴールhttps://qiita.com/hgsgtk/items/ daa d dacxUnit Test Patternsから学ぶテストアンチパターンhttps://speakerdeck.com/hgsgtk/testing-anti-pattern-learned-in-xunit-test-patternユニットテスト初⼼者を脱するために⾝につけたいN個のことhttps://speakerdeck.com/hgsgtk/n-points-to-get-out-of-unit-test-beginner-number-phpstudy
© - BASE, Inc.補⾜：関連資料テストが⾟いを解決するテスト駆動開発のアプローチhttps://speakerdeck.com/hgsgtk/tesutokaxin-iwojie-jue-surutesutoqu-dong-kai-fa-falseahuroti-at-phpkanhuarensuxian-tai-PHPバージョンアップと決済リプレイスを⽀えたユニットテストhttps://speakerdeck.com/hgsgtk/phpbaziyonatuputojue-ji-ripureisuwozhi-etayunitutotesuto-number-phpconテストを書いたことがないエンジニアがテストを書けるようになるまでやったことhttps://speakerdeck.com/hgsgtk/tesutowoshu-itakotokanaiensiniakatesutowoshu-keruyouninarumateyatutakoto-at-phpkanhuarensuguan-xi-
hgsgtk
lwug
yoshimi0227
nishiuma
murachiakira
muziyoshiz
pkshadeck
you
inureyes
naohachi89
aoshun7
pospome
taichinakamura
jponch
samlambert
zakiwarfel
chriscoyier
rocio
matthewcrist
searls
marcduiker
lauravandoore
speakerdeck
mthomps