WebAPI の自動テスト戦略 - Shin x Blog

テストコードを実装する際に単体テストで書くか、統合テストで書くか迷う場面はないでしょうか。本エントリでは、私なりのテスト戦略についての考えをまとめました。 概要 対象アプリケーション 本エントリにおける単体テストと統合テスト 単体テスト（ユニットテスト） 統合テスト（結合テスト、API テスト、フィーチャテスト） 単体テストと統合テストの特徴 テスト方針 テスト戦略 単体テストのみ 統合テストのみ 単体テストと統合テストを組み合わせる コンポーネント別のテストガイドライン 統合テストによるテスト テストピラミッドとテストダイヤモンド 統合テストの懸念 統合テストが無い 共有データセットが辛い 実行時間が遅くなりそう まとめ 参照 概要 単体テストと統合テストの特徴 テスト戦略 統合テストの懸念への対応 NotebookLM による音声概要を作成しました。よくまとまっているのでこちらもどうぞ

[shin1x1]

書きました

[auient]

基本は統合テストで、バリデーションとモデルは単体でやるといいよという指針は参考になる

[turanukimaru]

結合テストは導通テストだけ行い Post,Put,Get,Delete,Get のセットでやり他のデータに影響される項目はテストしない、みたいなガイドラインを作ると維持しやすくなる。コントローラの出力JSONのチェックとかは単体にできる。

[atsushifx]

個人的には、ユニットテスト重視かな。単体のコンポーネントはTDDなりなんなりで確保するのは基本として、記事内のドメイン、ユースケースレベルをユニットテスト+Mockやらで高速かつ安定にテストできたらいいかな

[FreeCatWork]

むずかしいお勉強…ボクにはわからにゃい！でも、頑張ったニャンコさん、えらいにゃ！

[hirorinya]

なるほど

[jsoizo]

ユースケースのテストはテストダブルになったとしてもユニットテスト書くかな。他コンポーネントの型が厳格であればモックすることの問題は減らせるし。