オブジェクト指向に基づいた ユニットテストのメリット#PHPerKaigi2023

PHPerKaigi 2023 day2 TrackA 12:10〜のセッションスライドです。
https://fortee.jp/phperkaigi-2023/proposal/afd2bc66-c65c-40e2-be51-ac2ad4c5a26d

Transcript

1. オブジェクト指向に基づいた ユニットテストのメリット PHPerKaigi 2023 伊神誠人(Makoto Ikami)
2. 自己紹介 • 伊神 誠人 • 株式会社カルテットコミュニケーションズ • 開発部 ◦ バックエンドエンジニア(PHP, Symfony) ◦ 最近はWeb広告のAPIをPHPで叩いている • Webマーケターの経験(広告運用・サイト分析) • SNS ◦ GitHub：@mako5656 ◦ Twitter：@mako5656_i
3. 本発表の構成 オブジェクト指向とユニットテスト 1 2 デザインパターン Dependency Injectin(DI) 3 まとめ 4
4. 話すこと/話さないこと • 話すこと ◦ テストを書くにあたってオブジェクト指向・デザインパターン・DIを 使用しているとそれぞれどのようなメリットがあるか • 話さないこと ◦ 各用語についての詳細 ◦ Web広告について
5. オブジェクト指向とユニットテスト
6. オブジェクト指向とユニットテストの概要 • オブジェクト指向 プログラムを構成する部品(オブジェクト)という単位に分割する方法 • ユニットテスト プログラムの小さな部品を自動的にテストする方法
7. 参考：http://objectclub.jp/technicaldoc/object-orientation/OO_redefine/redefine07 分割した場合 分割しない場合 オブジェクトごとに分割しない/した場合
8. オブジェクトごとに分割した場合のメリット 『保守性』 と 『拡張性』 が向上 オブジェクトごとが疎結合になり『責務』が明確になる テストとしても変更や追加に伴って修正が必要な箇所を特定しやすくなる
9. デザインパターン
10. デザインパターンの概要 ソフトウェア開発の共通の課題を解決するための設計手法を集めたもの 経験則に基づく知識を体系化したもので、ソフトウェア開発における設計の 問題を解決する際に利用される
11. デザインパターンを使用しない場合 FizzBuzz問題 • 1からNまでの数字を繰り返し処理 • 3で割り切れる場合は「Fizz」 • 5で割り切れる場合は「Buzz」 • 3でも5でも割り切れる場合は「FizzBuzz」 • それ以外はその数字
12. 今回使用するデザインパターン • Strategyパターン 複数の解決策を用意して必要に応じて切り替えることで 柔軟性を持たせるデザインパターン 実行時にストラテジーを切り替えることができ、メンテナンス性も高くなる
13. デザインパターン(Strategyパターン)を使用した場合
14. デザインパターン(Strategyパターン)を使用した場合 インターフェースを定義 文字列を生成するために実行される アルゴリズムをカプセル化するために使用
15. デザインパターン(Strategyパターン)を使用した場合 FizzStrategyクラス：3で割り切れる場合 BuzzStrategyクラス：5で割り切れる場合
16. デザインパターン(Strategyパターン)を使用した場合 引数として渡された数字に対する出力を生成
17. デザインパターン(Strategyパターン)を使用した場合 ループを使用して指定された値までルールに 従って文字列を生成
18. デザインパターンを使用しない/した場合の比較 • 使用しない場合 • 使用した場合
19. デザインパターンを使用しない/した場合の比較 • 使用しない場合 • 使用した場合 より多くのテストを書く必要がでてきたり、 出力が大量になった場合テストが困難になる
20. デザインパターンを使用しない/した場合の比較 • 使用しない場合 • 使用した場合 FizzStrategyとBuzzStrategyクラスは独自にテスト することができ、FizzBuzzクラスのテストも簡単
21. デザインパターンを使用しない/した場合の比較 • 使用しない場合 • 使用した場合 FooStrategyの追加とFizzBuzzクラスに 追加するだけで簡単に拡張可能
22. デザインパターンを使用することによるメリット • 柔軟性と再利用性の向上 新たなルールの追加する場合に既存のコードの影響を与えず追加可能 機能の追加、変更、削除が容易になることから、開発プロセスが迅速になる • コードの可読性を高める 設計や実装が一貫性を持つためコードの理解がしやすくなる
23. Dependency Injection (DI)
24. Dependency Injection (DI)の概要 依存関係のあるオブジェクトを外部から注入することにより、オブジェクトの 結合度を低くし柔軟性を高める手法 DIは制御の反転の一種で、オブジェクトの作成と利用について関心の分離 を行い、疎結合なプログラムを実現することを目的 としている
25. DIを使用しない/した場合 • 使用しない場合 • 使用した場合
26. DIを使用しない/した場合 • 使用しない場合 • 使用した場合 テストコード
27. DIを使用しない/した場合 • 使用しない場合 • 使用した場合 実装コード
28. DIを使用しない/した場合 • 使用しない場合 • 使用した場合
29. DIを使用しない場合
30. DIを使用しない場合 Calculatorクラスを直接インスタン ス化して、addメソッドを呼び出し 外部依存を持つ場合は、 テストが困難になることがある
31. DIを使用しない/した場合の比較 • 使用しない場合 • 使用した場合
32. DIを使用した場合
33. DIを使用した場合 CalculatorクラスがLoggerクラスに依存して いると仮定し、コンストラクタでLoggerオブ ジェクトを受け取っている
34. DIを使用した場合 TestLoggerクラスを作成して、 それをCalculatorクラスのコンストラクタに渡す テストをより疎結合にし、外部依存による テストの困難さを解決することができる
35. DIを使用することによるメリット • コードの保守性や拡張性が向上 依存関係が柔軟になることで、コンポーネントを簡単に交換できるようになる コードの記述量も減り可読性も向上する • テストのしやすさが向上 テスト時に依存するコンポーネントをモックオブジェクトに置き換えることができるようになる これにより、テストコードが単純化しテストの作成や実行が容易になる
36. まとめ
37. まとめ • テストを書くにあたってオブジェクト指向・デザインパターン・DIを使用 しているとそれぞれどのようなメリットがあるか ⇛ 効率的かつ品質の高いコードを実現 ⇛ テストとしても書きやすくなり効率性が向上 • テストはあくまで品質を担保するための手段
38. サービス紹介
41. ご清聴ありがとうございました