実践！ユニットテスト入門（PHPカンファレンス2022）

Transcript

1. 1 © 2012-2022 BASE, Inc. #phpcon2022 PHPカンファレンス2022（2022.09.24） 実践！ ユニットテスト入門 プログラミングをするパンダ (@Panda_Program) #phpcon2022
2. 2 © 2012-2022 BASE, Inc. #phpcon2022 感想をぜひ #phpcon2022
3. 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）
4. 4 © 2012-2022 BASE, Inc. #phpcon2022 自己紹介 個人開発が好き プログラミングをするパンダ（@Panda_Program） ブログ書いてます https://panda-program.com/ ビールの画像投稿サイト作りました https://beerbreak.info/ Next.js + Vercel + Supabase
5. 5 © 2012-2022 BASE, Inc. #phpcon2022 本発表の対象者
6. 6 © 2012-2022 BASE, Inc. #phpcon2022 本発表の対象者 ユニットテストを 書いたことがない 開発者
7. 7 © 2012-2022 BASE, Inc. #phpcon2022 本発表の構成 テストを書くための モチベーションを上げる １ 明日からテストを実践するための 知識を得る ２ ３ テストを通して、ソフトウェア開発の 全体像に触れる
8. 8 © 2012-2022 BASE, Inc. #phpcon2022 本発表の目標 入門者 → 初心者 １ 「初心者 → 中級者」 のスライド（「『質』 のいいユニットテストを書くためのプラク ティス」）に進める https://speakerdeck.com/hgsgtk/practices-to-write-better-unit-test ２ ３
9. 9 © 2012-2022 BASE, Inc. #phpcon2022 本発表の位置付け https://roadmap.sh/backend
10. 10 © 2012-2022 BASE, Inc. #phpcon2022 本発表の位置付け https://roadmap.sh/backend
11. 11 © 2012-2022 BASE, Inc. #phpcon2022 サンプルコードはPHP PHP以外でも通用する考え方
12. テストを書くための モチベーションを 上げる
13. 13 © 2012-2022 BASE, Inc. #phpcon2022 こんな話を聞いたことは ありませんか？
14. 14 © 2012-2022 BASE, Inc. #phpcon2022 実装は早いけど バグが多い
15. 15 © 2012-2022 BASE, Inc. #phpcon2022 テストをする
16. 16 © 2012-2022 BASE, Inc. #phpcon2022 テストの種類 手動テスト １ 自動テスト ２ ３
17. 17 © 2012-2022 BASE, Inc. #phpcon2022 テストの種類 手動テスト（画面ポチポチ） １ 自動テスト（テストコマンド実行） ２ ３
18. 18 © 2012-2022 BASE, Inc. #phpcon2022 バグを出さないために 自動テストをしよう
19. 19 © 2012-2022 BASE, Inc. #phpcon2022 自動テストは ユニットテストから 始めよう
20. 20 © 2012-2022 BASE, Inc. #phpcon2022 ユニットテストの 位置付けは？
21. 21 © 2012-2022 BASE, Inc. #phpcon2022 テストピラミッド
22. 22 © 2012-2022 BASE, Inc. #phpcon2022 テストピラミッド 「The Practical Test Pyramid」 https://martinfowler.com/articles/practical-test-pyramid.html
23. 23 © 2012-2022 BASE, Inc. #phpcon2022 ユニットテストを たくさん書くことになる
24. 24 © 2012-2022 BASE, Inc. #phpcon2022 PHPUnitの紹介 自動テストは、ユニットテストから始めると良い PHPでユニットテストをするために PHPUnit を使おう https://phpunit.de/
25. 25 © 2012-2022 BASE, Inc. #phpcon2022 テストクラスの作り方
26. 26 © 2012-2022 BASE, Inc. #phpcon2022 テストクラスの作り方
27. 27 © 2012-2022 BASE, Inc. #phpcon2022 テストクラスの作り方
28. 28 © 2012-2022 BASE, Inc. #phpcon2022 テストクラスの作り方
29. 29 © 2012-2022 BASE, Inc. #phpcon2022 テストクラスの作り方
30. 30 © 2012-2022 BASE, Inc. #phpcon2022 テストクラスの作り方
31. 31 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストの結果は3種類 . 成功したテスト（Success） F 失敗したテスト（Failure） E 予期せぬエラーで落ちたテスト（Error）
32. 32 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストが成功した = テストが通った（パスした） = テストがグリーンだ
33. 33 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果
34. 34 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストが失敗した = テストがレッドだ 実際の値と期待する値の 差分（=テスト失敗の理由）を 表示してくれる プロダクションコードか テストコードがおかしいのでコード を修正する
35. 35 © 2012-2022 BASE, Inc. #phpcon2022 テストの実行結果 テストが失敗した = テストがレッドだ 実際の値と期待する値の 差分（=テスト失敗の理由）を 表示してくれる プロダクションコードか テストコードがおかしいのでコード を修正する
36. 36 © 2012-2022 BASE, Inc. #phpcon2022 まとめ バグを出したくない → テストをしよう → 手動テストより自動テストが楽 →ユニットテストから始める
37. 明日からテストを 実践するための 知識を得る
38. 38 © 2012-2022 BASE, Inc. #phpcon2022 1. テストケースは日本語で書こう ユニットテストの実践知識 3. いろんな assertion を知ろう 5. dataProvider でテストケースをまとめよう 2. arrange / act / assert パターンで書こう 4. setUp / tearDown で前後の処理をしよう
39. テストケースは 日本語で書こう
40. 40 © 2012-2022 BASE, Inc. #phpcon2022 ・getTitle ・getTitle_should_return_post_title ・getTitle_投稿のタイトルを返す テストケースは日本語で書こう
41. 41 © 2012-2022 BASE, Inc. #phpcon2022 テストケースは日本語で書こう 1テストケースにつき、1メソッド テストケース名 = メソッド名なので、直感的に理解できる「日本語」がベスト 格言「コードは書く時間より、読まれる時間の方が長い」 格言「テストコードがドキュメントになるように書こう」 テストコードを読む人のことを考えて、テストケース名で このメソッドは何をしているのか（= what）を説明する
42. 42 © 2012-2022 BASE, Inc. #phpcon2022 テストケースは日本語で書こう https://twitter.com/t_wada/status/904916106153828352
43. 43 © 2012-2022 BASE, Inc. #phpcon2022 テストケースは日本語で書こう テストケース名のテクニック - 前提条件がある場合は、「method_Xのとき、Yを返す」と書く - 処理内容を一言で書きにくいときは、責務が多すぎる可能性あり - モデリングやクラス設計を見直してみる - 処理を private メソッドに切り出す / 処理をクラスに切り出す
44. 44 © 2012-2022 BASE, Inc. #phpcon2022 テストケース名のテクニック - 前提条件がある場合は、「method_Xのとき、Yを返す」と書く - 処理内容を一言で書きにくいときは、責務が多すぎる可能性あり - 処理を private メソッドに切り出す / 処理をクラスに切り出す - モデリングを見直してみる
45. arrange / act / assert パターンで書こう
46. 46 © 2012-2022 BASE, Inc. #phpcon2022 arrange / act / assert パターンで書こう ・constructor で投稿のタイトルを設定 　する ・getTitle で投稿のタイトルを取得する (PHP 8 だともっとシンプルに書けるが、 あえて省略していない） 「Arrange Act Assert」 http://wiki.c2.com/?ArrangeActAssert Post クラスを作ってみる
47. 47 © 2012-2022 BASE, Inc. #phpcon2022 arrange / act / assert パターンで書こう 「Arrange Act Assert」 http://wiki.c2.com/?ArrangeActAssert ・arrange で、前提条件と入力値を配置 する ・act で、テスト対象（メソッド）を実 行する ・assert で、期待した結果を得られるこ とをチェックする arrange / act / assert は テストの実装パターンの一つ
48. 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 は不要な時もある
49. 49 © 2012-2022 BASE, Inc. #phpcon2022 ちなみに
50. 50 © 2012-2022 BASE, Inc. #phpcon2022 初見のテストは、以下の順番に読むとわかりやすい （テクニック） 1. テストケース名 2. 検証内容 3. 前準備 4. テスト対象の実行
51. 51 © 2012-2022 BASE, Inc. #phpcon2022 初見のテストは、以下の順番に読むとわかりやすい （テクニック） 1. テストケース名 2. 検証内容　 ← assert 3. 前準備 ← arrange 4. テスト対象の実行 ← act
52. いろんな assertion を知ろう
53. 53 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう assertion（アサーション）は、値が真であることをプログラマが表明するためのもの $this->assertSame は最も基本となるアサーション 「期待する値」と「実際の値」を比較した結果、 同じならテストは success（成功）、違うなら fail（失敗）
54. 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
55. 55 © 2012-2022 BASE, Inc. #phpcon2022 他にもあります
56. 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
57. 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
58. 58 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう 各種アサーションは PHPUnit 由来のもの フレームワークが便利なアサーションを用意しているケースもある （ex. Laravel の assertDatabaseHas など）
59. 59 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう 配列をチェックするアサーションを並べてみた ・assertSame / assertCount / assertContains / assertNotEmpty
60. 60 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう 実際は、テストの意図をうまく表現できているアサーションだけで十分 → 1テストケース、1つの意図
61. 61 © 2012-2022 BASE, Inc. #phpcon2022 いろんな assertion を知ろう 分割
62. setUp / tearDown で 前後の処理をしよう
63. 63 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう 異なる2つのテストケースの arrange で重複が発生している
64. 64 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう 格言「繰り返しを避けること（ DRY原則。Don’t Repeat Yourself.）」 重複があるので、処理を共通化するリファクタリングを実施する （テストコードもリファクタリングの対象である）
65. 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
66. 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)）
67. 67 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう tearDown は、あるテストが他の テストに影響を与えないようにする ために使う ・時間の固定を解除、テーブルのレコードを 削除するなど ・（本来、プロパティの unset はしなくて良 い） 「PHPUnit Docs » 4. フィクスチャ」 https://phpunit.readthedocs.io/ja/latest/fixtures.html
68. 68 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう 重複していた arrange が...
69. 69 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう
70. 70 © 2012-2022 BASE, Inc. #phpcon2022 ちょっとした テクニック
71. 71 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう
72. 72 © 2012-2022 BASE, Inc. #phpcon2022 setUp / tearDown で前後の処理をしよう setUp にまとめるのではなく、 前処理用の private メソッドを作ってもいい - 今回の例なら、本当はこちらの方が適している - タイトルと本文が、テストケースごとに異なるため - テスト対象ではない値は空文字にするなど柔軟な対応ができる
73. dataProvider で テストケースをまとめよう
74. 74 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 今は本文（$body）が一行のテスト しかない 「本文($body)が改行を含むとき、 　getBody() を実行すると 改行が消えてしまうかも😰」 どうする？ (getter なのでそんなことはないが、一例として)
75. 75 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 本文に改行があるとき、改行が削除 されないか不安になった 󰢃 画面ぽちぽち 󰢃 var_dump での出力確認
76. 76 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 不安をテストで解消する 󰢏
77. 77 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう テストを追加して、挙動を確認する
78. 78 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 2つのテストケースの構造が同じ
79. 79 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 格言「繰り返しを避けること（ DRY原則。Don’t Repeat Yourself.）」 どこで共通化する？
80. 80 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 複数のテストケースの構造が同じ 󰢃 setUp にまとめる 全てのテストケースで重複しているわけではない （例えば、getTitle のテストケースでは arrange が異なる）
81. 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 複数のテストケースの構造が同じ 󰢏 データプロバイダーにまとめる 処理が同様なら、テストの変数は「入力値」と「期待値」だ け
82. 82 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう
83. 83 © 2012-2022 BASE, Inc. #phpcon2022 テストのロジックと 入力値・期待値のデータに 分ける
84. 84 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう 2つのテストケースの構造が同じ
85. 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
86. 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
87. 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
88. 88 © 2012-2022 BASE, Inc. #phpcon2022 注意点
89. 89 © 2012-2022 BASE, Inc. #phpcon2022 テストケースがない時に dataProvider から 書かない
90. 90 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう テストケースが重複してから初めて、dataProvider を使う。 最初から dataProvider を書き始めない。 「頭の中で考えて同じだから」ではなく 「目で見て」コードが重複していることを確認してから dataProvider を使う。 そうしなければ、各テストケースで 微妙に arrange が異なったり、assertion を増やしたい場合、 dataProvider を解体する手戻りが発生してしまうため。
91. 91 © 2012-2022 BASE, Inc. #phpcon2022 dataProvider でテストケースをまとめよう GitHub https://github.com/KushibikiMashu/unit-test-sample-php
92. テストを通して、 ソフトウェア開発の 全体像を学ぶ
93. 93 © 2012-2022 BASE, Inc. #phpcon2022 発展的な内容
94. 94 © 2012-2022 BASE, Inc. #phpcon2022 DevOps の考え方
95. 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
96. 96 © 2012-2022 BASE, Inc. #phpcon2022 テストの位置付け A Practical Guide to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition Continuous Testing
97. 97 © 2012-2022 BASE, Inc. #phpcon2022 テストの位置付け A Practical Guide to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition ユニットテスト （ローカル、CIで実行）
98. 98 © 2012-2022 BASE, Inc. #phpcon2022 テストピラミッド 「The Practical Test Pyramid」 https://martinfowler.com/articles/practical-test-pyramid.html
99. 99 © 2012-2022 BASE, Inc. #phpcon2022 テストピラミッドを 発展させた考え方
100. 100 © 2012-2022 BASE, Inc. #phpcon2022 バグフィルター
101. 101 © 2012-2022 BASE, Inc. #phpcon2022 DevOps バグフィルター A Practical Guide to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition ユニットテストで 小さいバグを捉える バグが本番にまで 行かないようにする = フィルター（網）
102. 102 © 2012-2022 BASE, Inc. #phpcon2022 ソフトウェアテストの7原則 （JSTQB (日本ソフトウェアテスト資格認定委員会)制定） 1. テストは「欠陥があること」しか示せない 2. 全数テストは不可能 …
103. 103 © 2012-2022 BASE, Inc. #phpcon2022 バグを避けるには どうすれば良いんだろう？
104. 104 © 2012-2022 BASE, Inc. #phpcon2022 本発表のAnswer ユニットテストから始めよう
105. 105 © 2012-2022 BASE, Inc. #phpcon2022 DevOps 的な Answer 1. みんなで、いろんなフェーズでテストをしよう 2. ただし、どれだけテストをしても本番でバグは出る （だから監視・アラートを開発者も見る） 3. 本番でバグが出ても、ユーザー影響を最小限にするた め、すぐに変更を戻そう
106. 106 © 2012-2022 BASE, Inc. #phpcon2022 コードを書いて 給料を貰っているなら あなたはプロフェッショナル
107. 107 © 2012-2022 BASE, Inc. #phpcon2022 プロフェッショナルなら テストを書いて ユーザーをバグから守ろう
108. 108 © 2012-2022 BASE, Inc. #phpcon2022 Clean Architecture も大事だが、まずは Clean Coder になろう
109. 109 © 2012-2022 BASE, Inc. #phpcon2022 ご清聴 ありがとうございました
110. 付録
111. 111 © 2012-2022 BASE, Inc. #phpcon2022 ①「質とスピード」
112. 112 © 2012-2022 BASE, Inc. #phpcon2022 内部品質が悪いと 実装スピードが遅くなる
113. 113 © 2012-2022 BASE, Inc. #phpcon2022 質とスピード 「質とスピード（2022春版、質疑応答用資料付き）」和田 卓人（@t_wada） https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition?slide=54
114. 114 © 2012-2022 BASE, Inc. #phpcon2022 質とスピード 「質とスピード（2022春版、質疑応答用資料付き）」和田 卓人（@t_wada） https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition?slide=54
115. 115 © 2012-2022 BASE, Inc. #phpcon2022 質とスピード 「質とスピード（2022春版、質疑応答用資料付き）」和田 卓人（@t_wada） https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition?slide=54
116. 116 © 2012-2022 BASE, Inc. #phpcon2022 「質とスピード」は ソフトウェア開発の 両輪
117. 117 © 2012-2022 BASE, Inc. #phpcon2022 Question. 実装は早いけどバグが出る Answer コードを綺麗に保ち続けないと、 機能追加、改修のたびに余分な工数が増える = 1ヶ月で実装速度が遅くなる →リファクタリングをし続けよう
118. 118 © 2012-2022 BASE, Inc. #phpcon2022 Question. 実装は早いけどバグが出る Answer バグの原因を分析しよう。原因は現場によって 様々なので、対処法はケースバイケース。 手動テスト、自動テストを組み合わせながら リリース前にバグを検知しよう。
119. 119 © 2012-2022 BASE, Inc. #phpcon2022 ②ユニットテストの 更なる力
120. 120 © 2012-2022 BASE, Inc. #phpcon2022 ユニットテストは 品質を高めるだけでなく 設計にも使える
121. 121 © 2012-2022 BASE, Inc. #phpcon2022 TDD TDD Test Driven Development テスト駆動開発
122. 122 © 2012-2022 BASE, Inc. #phpcon2022 TDD 「テスト駆動開発（TDD）とは何か。コードで実践方法を解説します」 https://panda-program.com/posts/test-driven-development 雑誌 ブログ 書籍
123. 123 © 2012-2022 BASE, Inc. #phpcon2022 TDD 「テスト駆動開発（TDD）とは何か。コードで実践方法を解説します」 https://panda-program.com/posts/test-driven-development
124. 124 © 2012-2022 BASE, Inc. #phpcon2022 XP の計画/フィードバックループ
125. 125 © 2012-2022 BASE, Inc. #phpcon2022 XP の計画/フィードバックループ
126. 126 © 2012-2022 BASE, Inc. #phpcon2022 テストを先に書くと テストを書き忘れない （テストファースト）
127. 127 © 2012-2022 BASE, Inc. #phpcon2022 実装方法がわからないとき、 テストを設計手法とする （Test Driven Development）
128. 128 © 2012-2022 BASE, Inc. #phpcon2022 ③TDDの限界
129. 129 © 2012-2022 BASE, Inc. #phpcon2022 TDD のテストは Testing ではなく Checking
130. 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
131. 131 © 2012-2022 BASE, Inc. #phpcon2022 アジャイルテストの 四象限
132. 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 開発を支援する 製品を評価 （批評）する 技術面 ビジネス面
133. 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 開発を支援する 製品を評価 （批評）する 技術面 ビジネス面
134. 134 © 2012-2022 BASE, Inc. #phpcon2022 DevOps バグフィルター A Practical Guide to Testing in DevOps Japanese Edition https://leanpub.com/testingindevops-japanese-edition 網目をすり抜けて 本番でバグが出る 可能性もある
135. 135 © 2012-2022 BASE, Inc. #phpcon2022 TDD のテストは Testing ではなく Checking
136. 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/
137. 137 © 2012-2022 BASE, Inc. #phpcon2022 TDDは テスト技法ではなく 設計手法である
138. 138 © 2012-2022 BASE, Inc. #phpcon2022 TDDは設計手法 https://roadmap.sh/backend
139. 139 © 2012-2022 BASE, Inc. #phpcon2022 テストカバレッジが 100%でも バグが出ないとは 言い切れない
140. 140 © 2012-2022 BASE, Inc. #phpcon2022 それでも開発者が書く 「テスト」には 大きな意味がある
141. 141 © 2012-2022 BASE, Inc. #phpcon2022 テストでユーザーを バグから守ろう
142. 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
143. 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
144. 144 © 2012-2022 BASE, Inc. #phpcon2022 Special Thanks 資料レビューありがとうございました！ キュアセブン（@cureseven、同僚） 02（@cocoeyes02、同僚） 東口さん（@hgsgtk、ex-BASE、Autify勤務）