変更につよいユニットテストの考え方

このプレゼンテーションでは、効果的なユニットテストの書き方について解説しています。主なトピックは以下の通りです：

ユニットテストの真の目的

開発者サポート
バグ防止
コードの信頼性向上

メンテナンス性を重視したテスト設計

プロダクションコードとテストコードの依存関係を排除
テストコード量の最適化

プログラムの振る舞いに基づくテスト戦略

ユースケースに基づいたテスト設計
各レイヤーに適した粒度でのテスト実装

効果的なテスト階層の構築

Featureテスト
UseCaseテスト
複雑なクラスに対する個別テスト

テストコード作成の具体的な方針

ユースケース実行の正確性を前提としたテスト
UseCaseテストによる振る舞いの保証
柔軟性を持たせたテストコード設計

新しい仕様への対応方法

既存の方針に基づいたテスト追加
複雑なロジックの分離とテスト

このアプローチを採用することで、変更に強いユニットテストを実現し、開発者の自信を高め、長期的な開発効率の向上につながります。メンテナンス性と効果的なテストカバレッジのバランスを取りながら、プロジェクトの品質を維持・向上させる方法を学べます。
対象者：

ソフトウェア開発者
テストエンジニア
プロジェクトマネージャー
品質保証チーム

キーワード：ユニットテスト、テスト設計、メンテナンス性、ユースケース、テスト階層、変更に強いコード

Transcript

1. 変更につよい ユニットテストの考え方 鈴木まー Funabashi.dev
2. 自己紹介 @suzuki_mar
3. 鈴木まー(suzuki_mar) RubyでDDDや モジュラーモノリスなど のソフトウェアアーキテクチャ の導入、定着を している PHP/Laravelで仕事をできるように 転職活動中＆スキルアップ中 直近の仕事 最近していること オブジェクト指向カンファレンスの動画を30ぽんぐらい公開した LTやブログなどで設計などをアウトプット PHP Sessionless Conferenceのコアスタッフになったばかり コミュニティ活動 @suzuki_mar プログラマー以外にプロレス団体のプロモーター的な 活動をボランティでしている 名古屋で3000人の会場を埋めることを考えている
4. 登壇をする前に @suzuki_mar 今回がはじめての20分の登壇なので 不手際があるかもしれないですけど よろしくお願いします
5. 話すこと @suzuki_mar
6. ユニットテストの目的を理解し、 プロダクションコードとテストコードの 依存関係を作らずに、 プログラミングの振る舞いに対して 各レイヤーの粒度にあった必要十分な テストを書いていく @suzuki_mar
7. 話さないこと @suzuki_mar ユニットテストの書き方など ユニットテストを書いてあることを 前提としています
8. ユニットテストの本や資料はたくさん あるのでそちらをみてください @suzuki_mar t-wadaさんの TDDBC Sendaの動画 https://www.youtube.com/watch?v=r0o54M0J850
9. 前提知識 ユースケースクラス @suzuki_mar
10. 自分の設計ではユースケースクラスが肝になってい るので今回もそれを使って説明をします ユースケースクラスとはAPIのリクエスト、レスポン ス以外のプログラムが何をするのかを書くクラス 前提知識 ユーケースクラス @suzuki_mar
12. ユースケースクラスを ADRパターンのACTIONクラス という認識でもOK 前提知識 ユーケースクラス @suzuki_mar
13. 前提知識 ユーケースクラス @suzuki_mar Action リクエストを受け取り、ドメインの処理結果をレスポンダに渡す Domain 必要な処理を行い結果を返すビジネスロジックはここに含まれる Responder ドメインの処理結果を受け取り、必要な準備を行いレスポンスを返す
14. 前提知識 ユーケースクラス @suzuki_mar 次のテキストをもとに 解説していきます
15. ユニットテストの目的を理解し、 プロダクションコードとテストコードの 依存関係を作らずに、 プログラムの振る舞いに対して 各レイヤーの粒度にあった必要十分な テストを書いていく
16. ユニットテストの目的 @suzuki_mar
17. よくある勘違い ユニットテストは プログラミングの品質を保証していて バグがないように テストをしているするもの ユニットテストの目的 @suzuki_mar
18. ユニットテストは、 開発者が想定している通りに プログラムが振る舞うことを テストを書きながら検証し、 保証するためのもの ユニットテストの目的 @suzuki_mar
19. 開発者が仕様を誤解していたり 仕様自体に誤りがある場合は バグが発生する ユニットテストの目的 @suzuki_mar
20. ユニットテストではバグが発生する 可能性があるのになんで時間をかけて テストコードを書く必要があるのか ユニットテストの目的 @suzuki_mar
21. ユニットテストは開発者用のテストとして 想定外の場所でバグが発生していないことを保証したり このコードはこの通りに動くという前提で プログラミングをすることができる ユニットテストの目的 @suzuki_mar 開発者のための安心ガード
22. E2Eテストや受け入れテスト ユニットテストの目的 @suzuki_mar 品質保証テスト ユニットテスト ｔ
23. E2Eテストや受け入れテスト ユニットテストの目的 @suzuki_mar 品質保証テスト ユニットテスト デベロッパーテスト ｔ 想定通りに動作しているかを素早く確認し、開発をサポート
24. ユニットテストの目的 @suzuki_mar ユニットテストは開発者を サポートするためのテスト メンテナンスしやすいように テストを書いていくことが大切 ｔ
25. ユニットテストの目的 @suzuki_mar ユニットテストがメンテナンス しづらいものだったら 開発者の足かせになってしまう 逆にｔ
26. ユニットテストの目的 @suzuki_mar メンテンナンスしやすいユニットテスト ｔ
27. ユニットテストの目的 @suzuki_mar メンテンナンスしやすいユニットテスト ｔ プロダクションコードが変更してもテストコードがこわれない
28. ユニットテストの目的 @suzuki_mar メンテンナンスしやすいユニットテスト ｔ プロダクションコードが変更してもテストコードがこわれない 開発者が実装した振る舞いをおこなうことが 保証されている最小限のテストコード
29. プロダクションコード とテストコードで 依存関係をつくらない @suzuki_mar
30. プロダクションコードとテストコードの 依存関係を作らずに
31. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar 依存関係があるとは プロダクションコードの定義を テストコードでも定義を参照してしまうため プロダクションコードの変更時 テストコードも壊れる ｔ
32. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar Userクラスに新しいユーザーを取得するメソッド User::fetchNewestが実装されているので 以下のテストコードを書いている ｔ どういうことか $this->assertNotNull(User::fetchNewest());
33. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar 仕様変更が発生して新しいユーザー を取得するのではなくて 認証している新しいユーザー を取得するということになり次のメソッド名になった ｔ User::fetchAuthenticatedNewest())
34. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar さきほどのテストコードを 次のように変更しないとけいない ｔ $this->assertNotNull(User::fetchNewest()); $this->assertNotNull(User::fetchAuthenticatedNewest())
35. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar わかりやすい例がprivate Method に対してテストコードをかいてしまうため 依存関係が生まれる private MethodはPublic Method よりも変更をする頻度がおおいためテストコードを 変更する必要になってしまう ｔ
36. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar 一つのメソッドだったら問題ないがこれが、 100個メソッドに対してテストを書いていたら 少しずつだけど塵が積もればとなり 負担になっていく ｔ
37. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar プロダクションコードとテストコードが 依存しているとCIを実行すると 度々テストコードが Error: Call to undefined method など のようなエラーをおこしてしまう
38. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar その結果 虚無状態になり ユニットテストを書きたくなくなる
39. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar どのようなテストを書いていくか
40. プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar プログラムの振る舞いに対 してテストを書いていく どのようなテストを書いていくか
41. プログラムの振る舞いに対して
42. プログラミングの振る舞い @suzuki_mar
43. プログラムの振る舞いは、定義された仕様に 従って動作することを指す 仕様の重要な部分は ユースケースとして記述される ユースケース記述は、各ユースケースの 詳細な流れや条件を説明している プログラミングの振る舞い @suzuki_mar
44. ユースケース記述は以下の項目が存在する アクター 誰が何をするか 前提条件 ユースケースを実行できるための条件 メインフロー　 ユースケースとして何をしていくか 代替フロー メインフローが実行できない場合にどうするか 事後条件 ユースケースの実行後に達成される結果や状態 プログラミングの振る舞い @suzuki_mar
45. ユースケース記述の例 ECサイトの注文 プログラミングの振る舞い @suzuki_mar
46. アクタÂ & 主アクター：購入4 & 副アクター：システム、CS（カスタマーサポート） 前提条件 ・購入者のIDが正しいこと 事後条件 ・商品が購入されている プログラミングの振る舞い @suzuki_mar
47. メインフロー 支払い情報を入力するま‡ cA システムは購入者がブラックリストに登録されていないことを確認すe &A 購入者がブラックリストに登録されている場合W $A システムは購入者に購入できない旨を通知すe $$A ユースケースを終了すe A 購入者が住所を入力すe `A システムは外部のアドレスチェックAPIに入力された住所が正しいことを問い合わせe &A 住所が間違っている場1 $A システムは購入者に住所が間違っていることを通知すe $$A 購入者に正しい住所の再入力を促す プログラミングの振る舞い @suzuki_mar
48. メインフロー 購入処理を終了するま‡ PS 購入者が支払い方法を選択する（クレジットカード、PayPay、モバイル決済D S システムは購入者の支払い能力を確認すB 3S 購入者の支払情報が間違っている場) S システムは購入者に支払い情報が間違っていることを通知すB S 購入者に正しい支払い情報の再入力を促w S 支払い能力を確認できない場合はユースケースを終了すB ÆS 購入者が商品を購入する プログラミングの振る舞い @suzuki_mar
49. サンプルコード プログラミングの振る舞い @suzuki_mar
51. 正常処理 購入に成功したことを確認している
52. ユースケースの実行Ⅱ 失敗したことのテスト ブラックリストに登録されている場合はカスタム例外ク ラスが発生している振る舞いをしているはず プロダクションコードとテストコードが依存している例 メッセージを変更するたびにテストコードを変更する必要がある 他の失敗したことのテストは同様に書いていく
53. 先ほどのようにテストコードを書いていけば、 実装者はユースケースがプログラムが想定している とおりに振る舞うと自信を持って言える プログラミングの振る舞い @suzuki_mar
54. BlackList::checkなどは 本当に自信をもっていると 動いていると言えるか プログラミングの振る舞い @suzuki_mar
55. ユーザーをブラックリストに入っていると 扱う条件は複雑 プログラミングの振る舞い @suzuki_mar 繰り返しの支払い失敗 不正な返金要求やチャージバックの頻発 虚偽の「商品未着」申告 不自然な頻度での返品や交換 複数アカウントの不正利用
56. ただ、これをユースケースのテストを書くと テストが複雑になってしまう そのため、BlackListのユニットテスト を書いたほうがいい プログラミングの振る舞い @suzuki_mar
57. Addressの確認はただ、 外部APIにアクセスするだけのシンプルな場合 AddressCheckerのテストを書かないでも ユースケースのテストだけで動いていると 自信を持っても良い プログラミングの振る舞い @suzuki_mar
58. 実装者が複雑だと思うものに対してだけ クラスに対してのテストコードを書いていく プログラミングの振る舞い @suzuki_mar
59. 各レイヤーの粒度にあった 必要十分な テストを書いていく @suzuki_mar
60. 各レイヤーの粒度にあった必要十分な テストを書いていく
61. ユースケースクラスがある場合の各レイヤー Featureテスト　 UseCaseテスト 個別のクラスのテスト 各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar
62. ユースケースの実行が正しく振る舞っていると過程して APIへのリクエストパラメーターのバリデーション等 が正しく実行されてること ユースケースが実行されている レスポンスで返すが正しいレスポンスコードなどが問題ないこと Featureテスト APIが正しく振る舞っていることの確認　 各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar
63. ステータスコードが正しいことのテスト
64. UseCaseが正しく実行されていることのテスト UseCaseが正しく振る舞っていると ordersにデータが作成されるという前提に立てる UseCaseが正しく振る舞っていることはUseCaseのテストで保証されている これだとUseCaseクラスのクラス名やメソッド名が変わっても テストコードを書き直す必要がない
65. ユースケース記述どおりに 振る舞っているかをテストする さきほど説明した以下のようなコードを書く UseCaseテスト　
66. 実装者が自信を持ててコードを書いていないものに 対してだけテストを書くメソッド名などは プロダクションコードと依存してもよい クラスに対するテスト　 一般的に簡単だと思えることでも実装者が難しい と思う場合はクラスに対するテストコードを書く
67. クラスに対するテスト　
68. BlackList::Checkは仕様が複雑だけどクラスに対してテスト コードをかいているため実装者の実装通りに クラスが振る舞うという前提にたてる そのため、BlackListに関することの ユースケースのテストは簡単なものでいい
69. 図解 Featureテスト (送信されたパラメーターが正しいかどなど) UseCaseテスト (ユースケース記述どおりにテストがじっこうさること) Featureテスト (UseCaseが実行されているか、ステータスコードが正しいか) 複雑な個別のクラスの テスト
70. このようにテストコード を作成すると必要十分な テストを書くことができる 各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar
71. テストコードが少ないほど ユニットテストのメンテナンス するものが少なくなる 結果、変更に強いユニットテストになる 各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar
72. まとめ @suzuki_mar
73. ユニットテストの目的 ユニットテストは開発者を サポートするためのテスト メンテナンスしやすいように テストを書いていくことが大切 各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar
74. プロダクションコードと テストコードの依存関係 各レイヤーの粒度にあった必要十分なテストを書いていく 依存しているとCIを実行すると 度々テストコードが Error: Call to undefined method など のようなエラーをおこしてしまう @suzuki_mar
75. プログラムの振る舞い 各レイヤーの粒度にあった必要十分なテストを書いていく 定義された仕様に 従って動作することを指す 仕様の重要な部分は ユースケースとして記述される ユースケース記述は、各ユースケースの 詳細な流れや条件を説明している @suzuki_mar
76. 各レイヤーの粒度にあった 各レイヤーの粒度にあった必要十分なテストを書いていく Featureテスト (送信されたパラメーターが正しいかどなど) UseCaseテスト (ユースケース記述どおりに テストが実行するか) Featureテスト (UseCaseが実行されているか、 ステータスコードが正しいか) 複雑な個別 のクラスの テスト
77. ユニットテストの目的を理解し、 プロダクションコードとテストコードの 依存関係を作らずに プログラムの振る舞いに対して 各レイヤーの粒度にあった必要十分な テストを書いていく @suzuki_mar
78. 新しい仕様が加わったら どうテストを書くか @suzuki_mar
79. みなさんも一緒に 考えてください @suzuki_mar 新しい仕様が加わったらどうテストを書くか
80. 新しい仕様が加わったらどうテストを書くか @suzuki_mar 在庫チェック RDBで在庫を管理しています 在庫が存在しない場合は エラーステータスコードを返す
81. 新しい仕様が加わったらどうテストを書くか @suzuki_mar 次のテストを書く
82. 新しい仕様が加わったらどうテストを書くか @suzuki_mar 在庫がない場合にユースケーステストで エラーが発生することをテストする 次のテストを書く
83. 在庫チェックはDBに データがあればいいので ユースケースだけのテストで十分 新しい仕様が加わったらどうテストを書くか @suzuki_mar
84. 新しい仕様が加わったらどうテストを書くか @suzuki_mar 在庫がないエラーがユースケースで発生した場合に APIのレスポンスとしてエラーステータスコード を返していることをテストする 次のテストを書く 在庫がない場合にユースケーステストで エラーが発生することをテストする
85. 在庫チェックでエラーが発生した場合は 新しくエラーステータスを返す必要 があるのでFeatureTestにそれを追加する 新しい仕様が加わったらどうテストを書くか @suzuki_mar
86. 新しい仕様が加わったらどうテストを書くか @suzuki_mar ポイント付与 ルール 通常のポイント付与 会員のステータスに応じた追加ポイント 商品の種類によるポイント付与率の変動 特定期間中の特別なポイント付与ルール 顧客の最初の購入に対する特別ボーナス 高額購入に対する追加ポイント
87. ポイント付与ルールは複雑なので 何ポイントを 付与するクラスを作成して そのクラスのためのテストを書く 新しい仕様が加わったらどうテストを書くか @suzuki_mar
89. ユースケースのテストにポイントが 付与されていることのテストをする クラスに対するテストを書いているため 何かしらのポイントが付与されていることを確認するだけでいい 新しい仕様が加わったらどうテストを書くか @suzuki_mar
90. 新しい仕様が加わったらどうテストを書くか @suzuki_mar
91. ポイント付与されても APIの振る舞いには 変化がないので FeatureTestにはテストを追加しない 新しい仕様が加わったらどうテストを書くか @suzuki_mar
92. 参考文献 @suzuki_mar
93. 参考文献 @suzuki_mar 単体テストや統合テストの基本から設計の重 要性まで幅広く解説し、 実践的なアプローチを提供しています。 Mocking戦略やTDDの設計行為としての役割 にも触れており、 テストコードの問題点にも洞察が得られま す。 引用 https://www.amazon.co.jp/product-reviews/4839981728/ref=acr_dpx_hist_5? ie=UTF8&filterByStar=five_star&reviewerType=all_reviews#reviews-filter-bar
94. 参考文献 @suzuki_mar ユースケースに基づく設計手法を丁寧に解説 し、設計から実装までの具体的な流れを学べ ます。複雑な要件整理やモデリングの実践例 も豊富に含まれ、理論だけでなく実践的なス キルを身につけたい開発者にとって非常に役 立つ一冊です。 引用 https://www.amazon.co.jp/product-reviews/4839981728/ref=acr_dpx_hist_5? ie=UTF8&filterByStar=five_star&reviewerType=all_reviews#reviews-filter-bar
95. 終わり