Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

実践!ユニットテスト入門(PHPカンファレンス2022)

panda_program
September 23, 2022

 実践!ユニットテスト入門(PHPカンファレンス2022)

panda_program

September 23, 2022
Tweet

More Decks by panda_program

Other Decks in Programming

Transcript

  1. 3 © 2012-2022 BASE, Inc. #phpcon2022 自己紹介 • BASE株式会社 •

    所属:BASE / Product Dev / CRM3 • 現在のお仕事:シニアエンジニア ◦ フロントエンドで React(Next.js)を書いたり Vue.js を書いたり ◦ バックエンドでは PHP を書いてます ◦ 最近は顧客管理機能(CRM)を開発してます • 好きなことと活動 ◦ DevOps とアジャイルの開発プロセス(特にXP)が好き ◦ Software Design 2022年3月号で TDD 特集の2,3部を執筆しました ◦ twitter: @Panda_Program プログラミングをするパンダ(@Panda_Program)
  2. 4 © 2012-2022 BASE, Inc. #phpcon2022 自己紹介 個人開発が好き プログラミングをするパンダ(@Panda_Program) ブログ書いてます

    https://panda-program.com/ ビールの画像投稿サイト作りました https://beerbreak.info/ Next.js + Vercel + Supabase
  3. 7 © 2012-2022 BASE, Inc. #phpcon2022 本発表の構成 テストを書くための モチベーションを上げる 1

    明日からテストを実践するための 知識を得る 2 3 テストを通して、ソフトウェア開発の 全体像に触れる
  4. 8 © 2012-2022 BASE, Inc. #phpcon2022 本発表の目標 入門者 → 初心者

    1 「初心者 → 中級者」 のスライド(「『質』 のいいユニットテストを書くためのプラク ティス」)に進める https://speakerdeck.com/hgsgtk/practices-to-write-better-unit-test 2 3
  5. 22 © 2012-2022 BASE, Inc. #phpcon2022 テストピラミッド 「The Practical Test

    Pyramid」 https://martinfowler.com/articles/practical-test-pyramid.html
  6. 31 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストの結果は3種類 . 成功したテスト(Success)

    F 失敗したテスト(Failure) E 予期せぬエラーで落ちたテスト(Error)
  7. 34 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストが失敗した = テストがレッドだ

    実際の値と期待する値の 差分(=テスト失敗の理由)を 表示してくれる プロダクションコードか テストコードがおかしいのでコード を修正する
  8. 35 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストが失敗した = テストがレッドだ

    実際の値と期待する値の 差分(=テスト失敗の理由)を 表示してくれる プロダクションコードか テストコードがおかしいのでコード を修正する
  9. 36 © 2012-2022 BASE, Inc. #phpcon2022 まとめ バグを出したくない → テストをしよう

    → 手動テストより自動テストが楽 →ユニットテストから始める
  10. 38 © 2012-2022 BASE, Inc. #phpcon2022 1. テストケースは日本語で書こう ユニットテストの実践知識 3.

    いろんな assertion を知ろう 5. dataProvider でテストケースをまとめよう 2. arrange / act / assert パターンで書こう 4. setUp / tearDown で前後の処理をしよう
  11. 41 © 2012-2022 BASE, Inc. #phpcon2022 テストケースは日本語で書こう 1テストケースにつき、1メソッド テストケース名 =

    メソッド名なので、直感的に理解できる「日本語」がベスト 格言「コードは書く時間より、読まれる時間の方が長い」 格言「テストコードがドキュメントになるように書こう」 テストコードを読む人のことを考えて、テストケース名で このメソッドは何をしているのか(= what)を説明する
  12. 43 © 2012-2022 BASE, Inc. #phpcon2022 テストケースは日本語で書こう テストケース名のテクニック - 前提条件がある場合は、「method_Xのとき、Yを返す」と書く

    - 処理内容を一言で書きにくいときは、責務が多すぎる可能性あり - モデリングやクラス設計を見直してみる - 処理を private メソッドに切り出す / 処理をクラスに切り出す
  13. 44 © 2012-2022 BASE, Inc. #phpcon2022 テストケース名のテクニック - 前提条件がある場合は、「method_Xのとき、Yを返す」と書く -

    処理内容を一言で書きにくいときは、責務が多すぎる可能性あり - 処理を private メソッドに切り出す / 処理をクラスに切り出す - モデリングを見直してみる
  14. 46 © 2012-2022 BASE, Inc. #phpcon2022 arrange / act /

    assert パターンで書こう ・constructor で投稿のタイトルを設定  する ・getTitle で投稿のタイトルを取得する (PHP 8 だともっとシンプルに書けるが、 あえて省略していない) 「Arrange Act Assert」 http://wiki.c2.com/?ArrangeActAssert Post クラスを作ってみる
  15. 47 © 2012-2022 BASE, Inc. #phpcon2022 arrange / act /

    assert パターンで書こう 「Arrange Act Assert」 http://wiki.c2.com/?ArrangeActAssert ・arrange で、前提条件と入力値を配置 する ・act で、テスト対象(メソッド)を実 行する ・assert で、期待した結果を得られるこ とをチェックする arrange / act / assert は テストの実装パターンの一つ
  16. 48 © 2012-2022 BASE, Inc. #phpcon2022 arrange / act /

    assert パターンで書こう 「Arrange Act Assert」 http://wiki.c2.com/?ArrangeActAssert arrange / act / assert パターンの メリット ・1テストケース 1act を意識できる  ・左画像で getEditors は不要だとわかる  ・複数の act があればテストケースを分ける ・自分が今どこを書いているのか自覚できる  ・次に何を書くのか迷わなくなる なお、arrange は不要な時もある
  17. 53 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう assertion(アサーション)は、値が真であることをプログラマが表明するためのもの

    $this->assertSame は最も基本となるアサーション 「期待する値」と「実際の値」を比較した結果、 同じならテストは success(成功)、違うなら fail(失敗)
  18. 54 © 2012-2022 BASE, Inc. #phpcon2022 assertSame($val1, $val2) assertTrue($value) assertNull($value)

    assertEquals($val1,$val2) assertFalse($value) 値の厳密な比較(===相当) $value が true である $value が null である 値の緩い比較(==相当) $value が false である いろんな assertion を知ろう 「PHPUnit Docs » 1. アサーション」 https://phpunit.readthedocs.io/ja/latest/assertions.html
  19. 56 © 2012-2022 BASE, Inc. #phpcon2022 assertCount($num, $arr) assertContains($val, $arr)

    assertRegExp($ptn, $str) assertEmpty($arr) assertArrayHasKey($key, $arr) 配列 $arr の要素が $num 個である 配列 $arr が $val を含んでいる 文字列 $str がパターン $ptn に マッチする 配列 $arr が空配列である 配列 $arr にキー $key が含まれている いろんな assertion を知ろう 「PHPUnit Docs » 1. アサーション」 https://phpunit.readthedocs.io/ja/latest/assertions.html
  20. 57 © 2012-2022 BASE, Inc. #phpcon2022 assertGreaterThan ($num1, $num2) assertFileExists($path)

    expectException($className) assertGreaterThanOrEqual ($num1, $num2) assertInstanceOf ($className, $instance) $num1 が $num2 より小さい ($num1 < $num2) ファイルパス $path にファイルがある $className の例外を throw する $num1 が $num2 以下である ($num1 <= $num2) $instance がクラス $className の インスタンスである いろんな assertion を知ろう 「PHPUnit Docs » 1. アサーション」 https://phpunit.readthedocs.io/ja/latest/assertions.html
  21. 58 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう 各種アサーションは

    PHPUnit 由来のもの フレームワークが便利なアサーションを用意しているケースもある (ex. Laravel の assertDatabaseHas など)
  22. 63 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう

    異なる2つのテストケースの arrange で重複が発生している
  23. 64 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう

    格言「繰り返しを避けること( DRY原則。Don’t Repeat Yourself.)」 重複があるので、処理を共通化するリファクタリングを実施する (テストコードもリファクタリングの対象である)
  24. 65 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう

    前処理を setUp にまとめる ・setUp に、そのクラスの全てのテストケース  に共通な前処理(arrange) をまとめる ・setUp は、各テストケースの直前に必ず  実行される 後処理を tearDown にまとめる ・テストの前処理は setUp に、後処理は  tearDown に記述する 「PHPUnit Docs » 4. フィクスチャ」 https://phpunit.readthedocs.io/ja/latest/fixtures.html
  25. 66 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう

    「PHPUnit Docs » 4. フィクスチャ」 https://phpunit.readthedocs.io/ja/latest/fixtures.html setUp では、各テストケースに共通な arrange をまとめる ・オブジェクトの生成や日付管理ライブラリ で時間固定、DBへの接続に使うことが多い  ・依存関係の解決(ex. new      PostPresenter(new Post))
  26. 67 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう

    tearDown は、あるテストが他の テストに影響を与えないようにする ために使う ・時間の固定を解除、テーブルのレコードを 削除するなど ・(本来、プロパティの unset はしなくて良 い) 「PHPUnit Docs » 4. フィクスチャ」 https://phpunit.readthedocs.io/ja/latest/fixtures.html
  27. 72 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう

    setUp にまとめるのではなく、 前処理用の private メソッドを作ってもいい - 今回の例なら、本当はこちらの方が適している - タイトルと本文が、テストケースごとに異なるため - テスト対象ではない値は空文字にするなど柔軟な対応ができる
  28. 74 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 今は本文($body)が一行のテスト しかない

    「本文($body)が改行を含むとき、  getBody() を実行すると 改行が消えてしまうかも😰」 どうする? (getter なのでそんなことはないが、一例として)
  29. 80 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 複数のテストケースの構造が同じ 󰢃

    setUp にまとめる 全てのテストケースで重複しているわけではない (例えば、getTitle のテストケースでは arrange が異なる)
  30. 81 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 「PHPUnit Docs

    » 2. PHPUnit 用のテストの書き方(データプロバイダ)」 https://phpunit.readthedocs.io/ja/latest/writing-tests-for-phpunit.html#writing-tests-for-phpunit-data-providers 複数のテストケースの構造が同じ 󰢏 データプロバイダーにまとめる 処理が同様なら、テストの変数は「入力値」と「期待値」だ け
  31. 85 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう ロジック側 ・複数のテストケースで共通の処理

    を1つにまとめる ・テストメソッドに引数を追加  ・入力値と期待する値(データ) を受け取る 「PHPUnit Docs » 2. PHPUnit 用のテストの書き方(データプロバイダ)」 https://phpunit.readthedocs.io/ja/latest/writing-tests-for-phpunit.html#writing-tests-for-phpunit-data-providers
  32. 86 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう データ側 ・データプロバイダーは、テストのデー

    タセットを配列で返す ・アノテーション @dataProvider は、 データを受け取るテストメソッドに書く ・データプロバイダー名は「テスト対象 のメソッド名 + Provider」がおすすめ  ・今回は getBodyProvider 「PHPUnit Docs » 2. PHPUnit 用のテストの書き方(データプロバイダ)」 https://phpunit.readthedocs.io/ja/latest/writing-tests-for-phpunit.html#writing-tests-for-phpunit-data-providers
  33. 87 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう データ側 ・返り値は配列

    (厳密には Iterator インターフェース を実装していれば良い) ・キーにテストケース名、値に入力値と 期待する値を指定する ・メリット  ・テストケースをまとめられる  ・バリエーションの追加が簡単 「PHPUnit Docs » 2. PHPUnit 用のテストの書き方(データプロバイダ)」 https://phpunit.readthedocs.io/ja/latest/writing-tests-for-phpunit.html#writing-tests-for-phpunit-data-providers
  34. 90 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう テストケースが重複してから初めて、dataProvider を使う。

    最初から dataProvider を書き始めない。 「頭の中で考えて同じだから」ではなく 「目で見て」コードが重複していることを確認してから dataProvider を使う。 そうしなければ、各テストケースで 微妙に arrange が異なったり、assertion を増やしたい場合、 dataProvider を解体する手戻りが発生してしまうため。
  35. 95 © 2012-2022 BASE, Inc. #phpcon2022 テストの位置付け Wikipedia - DevOps

    https://ja.wikipedia.org/wiki/DevOps#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%A B:Devops-toolchain.svg
  36. 96 © 2012-2022 BASE, Inc. #phpcon2022 テストの位置付け A Practical Guide

    to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition Continuous Testing
  37. 97 © 2012-2022 BASE, Inc. #phpcon2022 テストの位置付け A Practical Guide

    to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition ユニットテスト (ローカル、CIで実行)
  38. 98 © 2012-2022 BASE, Inc. #phpcon2022 テストピラミッド 「The Practical Test

    Pyramid」 https://martinfowler.com/articles/practical-test-pyramid.html
  39. 101 © 2012-2022 BASE, Inc. #phpcon2022 DevOps バグフィルター A Practical

    Guide to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition ユニットテストで 小さいバグを捉える バグが本番にまで 行かないようにする = フィルター(網)
  40. 105 © 2012-2022 BASE, Inc. #phpcon2022 DevOps 的な Answer 1.

    みんなで、いろんなフェーズでテストをしよう 2. ただし、どれだけテストをしても本番でバグは出る (だから監視・アラートを開発者も見る) 3. 本番でバグが出ても、ユーザー影響を最小限にするた め、すぐに変更を戻そう
  41. 117 © 2012-2022 BASE, Inc. #phpcon2022 Question. 実装は早いけどバグが出る Answer コードを綺麗に保ち続けないと、

    機能追加、改修のたびに余分な工数が増える = 1ヶ月で実装速度が遅くなる →リファクタリングをし続けよう
  42. 118 © 2012-2022 BASE, Inc. #phpcon2022 Question. 実装は早いけどバグが出る Answer バグの原因を分析しよう。原因は現場によって

    様々なので、対処法はケースバイケース。 手動テスト、自動テストを組み合わせながら リリース前にバグを検知しよう。
  43. 130 © 2012-2022 BASE, Inc. #phpcon2022 ソフトウェアテストの7原則 (JSTQB (日本ソフトウェアテスト資格認定委員会)制定) 1.

    テストは「欠陥があること」しか示せない 2. 全数テストは不可能 … ソフトウェアテストの7原則 https://hkawabata.github.io/technical-note/note/Principle/7-Principl es-of-Software-Test.html
  44. 132 © 2012-2022 BASE, Inc. #phpcon2022 アジャイルテストの四象限 Using Models to

    Help Plan Tests in Agile Projects https://www.informit.com/articles/article.aspx?p=2253544&ranMID=24808 開発を支援する 製品を評価 (批評)する 技術面 ビジネス面
  45. 133 © 2012-2022 BASE, Inc. #phpcon2022 アジャイルテストの四象限 Using Models to

    Help Plan Tests in Agile Projects https://www.informit.com/articles/article.aspx?p=2253544&ranMID=24808 開発を支援する 製品を評価 (批評)する 技術面 ビジネス面
  46. 134 © 2012-2022 BASE, Inc. #phpcon2022 DevOps バグフィルター A Practical

    Guide to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition 網目をすり抜けて 本番でバグが出る 可能性もある
  47. 136 © 2012-2022 BASE, Inc. #phpcon2022 Example-guided development (TDD, BDD,

    ATDD を xDD としてまとめた呼び方) 「Example-guided development: A useful abstraction for the xDD family?」 https://cucumber.io/blog/bdd/example-guided-development/
  48. 142 © 2012-2022 BASE, Inc. #phpcon2022 さらなる学習のための資料 TDD(テスト駆動開発) 「テスト自動化とテスト駆動開発」講演資料(@yattom) https://yattom.hatenablog.com/entry/2021/04/01/102052

    「質問5. 実際にTDDで運用したとき、それでも不具合が発生したことがありました。 データの量、質が問題視されたことがありました。 受け取った情報の信憑性は会話し ながら模索しないといけないのでしょうか」(@yattom) https://yattom.hatenablog.com/entry/2021/04/04/171531 「テスト駆動開発の題材を目的別で紹介する」(@nihonbuson) https://nihonbuson.hatenadiary.jp/entry/2021/08/16/090000 「SymfonyとDoctrineで簡単クリーンアーキテクチャ 〜プロトタイピングにこそクリーンなTDD が活きた話〜 」(ページ下部に動画あり) https://fortee.jp/phpcon-2021/proposal/37d95a00-37bd-41e3-bc4a-7db9414d7597
  49. 143 © 2012-2022 BASE, Inc. #phpcon2022 さらなる学習のための資料 ATDD 「TDDからATDDへ歩みをすすめる /

    Step to Acceptance test–driven development from TDD」(@hgsgtk) https://speakerdeck.com/hgsgtk/step-to-acceptance-test-driven-development-from-tdd モックを使った開発 「実践テスト駆動開発」 https://www.amazon.co.jp/dp/4798124583 「スタブ・モックは本当に悪者なのか?〜テスト駆動開発をやめて、なお残すべき習慣とは (2)」 https://twop.agile.esm.co.jp/finding-a-blind-spot-by-agile-test-quadrant-807179783360 DevOps の観点から 「A Practical Guide to Testing in DevOps Japanese Edition」(日本語) https://leanpub.com/testingindevops-japanese-edition