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

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

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

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

Makoto Ikami

March 22, 2023
Tweet

More Decks by Makoto Ikami

Other Decks in Technology

Transcript

  1. オブジェクト指向に基づいた
    ユニットテストのメリット
    PHPerKaigi 2023 伊神誠人(Makoto Ikami)

    View full-size slide

  2. 自己紹介
    ● 伊神 誠人
    ● 株式会社カルテットコミュニケーションズ
    ● 開発部
    ○ バックエンドエンジニア(PHP, Symfony)
    ○ 最近はWeb広告のAPIをPHPで叩いている
    ● Webマーケターの経験(広告運用・サイト分析)
    ● SNS
    ○ GitHub:@mako5656
    ○ Twitter:@mako5656_i

    View full-size slide

  3. 本発表の構成
    オブジェクト指向とユニットテスト
    1
    2 デザインパターン
    Dependency Injectin(DI)
    3
    まとめ
    4

    View full-size slide

  4. 話すこと/話さないこと
    ● 話すこと
    ○ テストを書くにあたってオブジェクト指向・デザインパターン・DIを
    使用しているとそれぞれどのようなメリットがあるか
    ● 話さないこと
    ○ 各用語についての詳細
    ○ Web広告について

    View full-size slide

  5. オブジェクト指向とユニットテスト

    View full-size slide

  6. オブジェクト指向とユニットテストの概要
    ● オブジェクト指向
    プログラムを構成する部品(オブジェクト)という単位に分割する方法
    ● ユニットテスト
    プログラムの小さな部品を自動的にテストする方法

    View full-size slide

  7. 参考:http://objectclub.jp/technicaldoc/object-orientation/OO_redefine/redefine07
    分割した場合
    分割しない場合
    オブジェクトごとに分割しない/した場合

    View full-size slide

  8. オブジェクトごとに分割した場合のメリット
    『保守性』 と 『拡張性』 が向上
    オブジェクトごとが疎結合になり『責務』が明確になる
    テストとしても変更や追加に伴って修正が必要な箇所を特定しやすくなる

    View full-size slide

  9. デザインパターン

    View full-size slide

  10. デザインパターンの概要
    ソフトウェア開発の共通の課題を解決するための設計手法を集めたもの
    経験則に基づく知識を体系化したもので、ソフトウェア開発における設計の
    問題を解決する際に利用される

    View full-size slide

  11. デザインパターンを使用しない場合
    FizzBuzz問題
    ● 1からNまでの数字を繰り返し処理
    ● 3で割り切れる場合は「Fizz」
    ● 5で割り切れる場合は「Buzz」
    ● 3でも5でも割り切れる場合は「FizzBuzz」
    ● それ以外はその数字

    View full-size slide

  12. 今回使用するデザインパターン
    ● Strategyパターン
    複数の解決策を用意して必要に応じて切り替えることで
    柔軟性を持たせるデザインパターン
    実行時にストラテジーを切り替えることができ、メンテナンス性も高くなる

    View full-size slide

  13. デザインパターン(Strategyパターン)を使用した場合

    View full-size slide

  14. デザインパターン(Strategyパターン)を使用した場合
    インターフェースを定義
    文字列を生成するために実行される
    アルゴリズムをカプセル化するために使用

    View full-size slide

  15. デザインパターン(Strategyパターン)を使用した場合
    FizzStrategyクラス:3で割り切れる場合
    BuzzStrategyクラス:5で割り切れる場合

    View full-size slide

  16. デザインパターン(Strategyパターン)を使用した場合
    引数として渡された数字に対する出力を生成

    View full-size slide

  17. デザインパターン(Strategyパターン)を使用した場合
    ループを使用して指定された値までルールに
    従って文字列を生成

    View full-size slide

  18. デザインパターンを使用しない/した場合の比較
    ● 使用しない場合 ● 使用した場合

    View full-size slide

  19. デザインパターンを使用しない/した場合の比較
    ● 使用しない場合 ● 使用した場合
    より多くのテストを書く必要がでてきたり、
    出力が大量になった場合テストが困難になる

    View full-size slide

  20. デザインパターンを使用しない/した場合の比較
    ● 使用しない場合 ● 使用した場合
    FizzStrategyとBuzzStrategyクラスは独自にテスト
    することができ、FizzBuzzクラスのテストも簡単

    View full-size slide

  21. デザインパターンを使用しない/した場合の比較
    ● 使用しない場合 ● 使用した場合
    FooStrategyの追加とFizzBuzzクラスに
    追加するだけで簡単に拡張可能

    View full-size slide

  22. デザインパターンを使用することによるメリット
    ● 柔軟性と再利用性の向上
    新たなルールの追加する場合に既存のコードの影響を与えず追加可能
    機能の追加、変更、削除が容易になることから、開発プロセスが迅速になる
    ● コードの可読性を高める
    設計や実装が一貫性を持つためコードの理解がしやすくなる

    View full-size slide

  23. Dependency Injection (DI)

    View full-size slide

  24. Dependency Injection (DI)の概要
    依存関係のあるオブジェクトを外部から注入することにより、オブジェクトの
    結合度を低くし柔軟性を高める手法
    DIは制御の反転の一種で、オブジェクトの作成と利用について関心の分離
    を行い、疎結合なプログラムを実現することを目的
    としている

    View full-size slide

  25. DIを使用しない/した場合
    ● 使用しない場合 ● 使用した場合

    View full-size slide

  26. DIを使用しない/した場合
    ● 使用しない場合 ● 使用した場合
    テストコード

    View full-size slide

  27. DIを使用しない/した場合
    ● 使用しない場合 ● 使用した場合
    実装コード

    View full-size slide

  28. DIを使用しない/した場合
    ● 使用しない場合 ● 使用した場合

    View full-size slide

  29. DIを使用しない場合

    View full-size slide

  30. DIを使用しない場合
    Calculatorクラスを直接インスタン
    ス化して、addメソッドを呼び出し
    外部依存を持つ場合は、
    テストが困難になることがある

    View full-size slide

  31. DIを使用しない/した場合の比較
    ● 使用しない場合 ● 使用した場合

    View full-size slide

  32. DIを使用した場合

    View full-size slide

  33. DIを使用した場合
    CalculatorクラスがLoggerクラスに依存して
    いると仮定し、コンストラクタでLoggerオブ
    ジェクトを受け取っている

    View full-size slide

  34. DIを使用した場合
    TestLoggerクラスを作成して、
    それをCalculatorクラスのコンストラクタに渡す
    テストをより疎結合にし、外部依存による
    テストの困難さを解決することができる

    View full-size slide

  35. DIを使用することによるメリット
    ● コードの保守性や拡張性が向上
    依存関係が柔軟になることで、コンポーネントを簡単に交換できるようになる
    コードの記述量も減り可読性も向上する
    ● テストのしやすさが向上
    テスト時に依存するコンポーネントをモックオブジェクトに置き換えることができるようになる
    これにより、テストコードが単純化しテストの作成や実行が容易になる

    View full-size slide

  36. まとめ
    ● テストを書くにあたってオブジェクト指向・デザインパターン・DIを使用
    しているとそれぞれどのようなメリットがあるか
    ⇛ 効率的かつ品質の高いコードを実現
    ⇛ テストとしても書きやすくなり効率性が向上
    ● テストはあくまで品質を担保するための手段

    View full-size slide

  37. サービス紹介

    View full-size slide

  38. ご清聴ありがとうございました

    View full-size slide