Upgrade to Pro — share decks privately, control downloads, hide ads and more …

実践!ユニットテスト入門(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. 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 本発表の構成 テストを書くための モチベーションを上げる 1

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

    1 「初心者 → 中級者」 のスライド(「『質』 のいいユニットテストを書くためのプラク ティス」)に進める https://speakerdeck.com/hgsgtk/practices-to-write-better-unit-test 2 3
  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 テストの種類 手動テスト 1 自動テスト

    2 3
  17. 17 © 2012-2022 BASE, Inc. #phpcon2022 テストの種類 手動テスト(画面ポチポチ) 1 自動テスト(テストコマンド実行)

    2 3
  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勤務)