Integration Test
結合テスト、統合テスト、インテグレーションテスト
『単体テストの考え方/使い方』.iconでのIntegration Testの定義
Unit Testではないtestのこと
つまり、以下の3つの内、一つでも満たさないものがあればIntegration Testである
1単位の振る舞いを検証する
実行時間が短い
他のtest caseから隔離されている
参考
/mrsekut-book-4839981728/279 (8.1 結合(integration)テストとは？)
#WIP
ドメインモデルとプロセス外依存を結びつけるコードを検証する
つまりController的なもの
ドメインモデル自体のテストは単体テストでやる
どういうものをテストするか
1件のhappy path
/mrsekut-book-4839981728/283
中でも、全てのプロセス外依存とやり取りするような長いpathを選ぶ
にしても曖昧では？
ログインが完了する、までで良いのか
ログインして投稿してログアウトするまで、が良いのか
さすがに前者mrsekut.icon
/mrsekut-book-4839981728/306
一つのテストケースでは、一つのAAA
単体テストでは扱えなかった全ての異常ケース
ただし、早期失敗するようになっているなら不要
実装の詳細との関わりが小さいのでリファクタの耐性がある
そもそもコストが高いので、明確な価値をもたらすコードのみをテストする
本番環境で全てのバグが出ないようにすることが目的ではない
データが壊れないバグならテストしなくても良い、ぐらいに割り切る
1個1このサイズ
あらゆるテスト対象を1個のsuitの中に含めちゃって良いのか
ちゃんと分割したほうが良いのか
普通に考えるとこっちのほうが良さそうだが
具体例
/mrsekut-book-4839981728/290 (どのように統合(integration)テストを行うのか？)~
最長のhappy pathを選択する
そのpathに登場するプロセス外依存を分析する
managedなのかunmanagedなのかを見極める
実行する
/mrsekut-book-4839981728/295
データをDBに保存しておく
テストを実行する
DBを見て正しいデータが入ってるか確認する
この定義に沿うなら、Testing Libraryでやってるのも殆どが単体テストに分類されるねmrsekut.icon
mockの有無は定義に関係ない
React HooksのTestと言ってもいくつか種類がある
DOMの存在を前提としているもの
例えばinput要素を用意して値を入力するやつとか
hooks単体でテストするもの
統合(integration) テストとは、簡単に言えば、共有依存やプロセス外依存、 さらには、 同じ組織内の異なるチームによって開発されたコードが統合された状態で想定通りに機能す ることを検証するテストのことです。 /mrsekut-book-4839981728/070
1つか2つのプロセス外依存を扱う
https://pirosikick.github.io/integration-test-is-awesome/#slide-1
https://zenn.dev/takepepe/articles/nextjs13-components-integration-test
next.js
https://zenn.dev/takepepe/articles/testing-gssp-and-api-routes
next.js
https://youtu.be/5H3Sswp5qYg?t=1153
Testing LibraryはIntegration testが対象
単体テストで確認した部品を他システム間とのインターフェースをテストする
他システムとは、OS,ファイルシステム、ハードウェア、などなど
複数のunit testを互いに統合したもの
mockはできるだけ使わない
MSWを使ったmockありのページ全体のテストとか
https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests#integration
具体例
@testing-library/user-event
MSW
@jackfranklin/test-data-bot
あたりを使っている
Enzyme
参考になりそうなプロジェクト
react-hook-formのcode reading
かなり豊富にtest書いてる
/mrsekut-book-4839981728/068 (2.4 古典学派およびロンドン学派における統合テスト)