generated at
Integration Test


『単体テストの考え方でのIntegration Testの定義
Unit Testではないtestのこと
つまり、以下の3つの内、一つでも満たさないものがあればIntegration Testである
1単位の振る舞いを検証する
実行時間が短い
他のtest caseから隔離されている



参考






ドメインモデルとプロセス外依存を結びつけるコードを検証する
つまりController的なもの
ドメインモデル自体のテストは単体テストでやる
どういうものをテストするか
1件のhappy path
中でも、全てのプロセス外依存とやり取りするような長いpathを選ぶ
にしても曖昧では?
ログインが完了する、までで良いのか
ログインして投稿してログアウトするまで、が良いのか
さすがに前者mrsekut
一つのテストケースでは、一つのAAA
単体テストでは扱えなかった全ての異常ケース
ただし、早期失敗するようになっているなら不要

実装の詳細との関わりが小さいのでリファクタの耐性がある
そもそもコストが高いので、明確な価値をもたらすコードのみをテストする
本番環境で全てのバグが出ないようにすることが目的ではない
データが壊れないバグならテストしなくても良い、ぐらいに割り切る


1個1このサイズ
あらゆるテスト対象を1個のsuitの中に含めちゃって良いのか
ちゃんと分割したほうが良いのか
普通に考えるとこっちのほうが良さそうだが

具体例
最長のhappy pathを選択する
そのpathに登場するプロセス外依存を分析する
managedなのかunmanagedなのかを見極める
実行する
データをDBに保存しておく
テストを実行する
DBを見て正しいデータが入ってるか確認する



この定義に沿うなら、Testing Libraryでやってるのも殆どが単体テストに分類されるねmrsekut
mockの有無は定義に関係ない
React HooksのTestと言ってもいくつか種類がある
DOMの存在を前提としているもの
例えばinput要素を用意して値を入力するやつとか
hooks単体でテストするもの





>統合(integration) テストとは、簡単に言えば、共有依存やプロセス外依存、 さらには、 同じ組織内の異なるチームによって開発されたコードが統合された状態で想定通りに機能す ることを検証するテストのことです。 /mrsekut-book-4839981728/070
1つか2つのプロセス外依存を扱う


next.js
next.js



Testing LibraryはIntegration testが対象
単体テストで確認した部品を他システム間とのインターフェースをテストする
他システムとは、OS,ファイルシステム、ハードウェア、などなど
複数のunit testを互いに統合したもの
mockはできるだけ使わない
MSWを使ったmockありのページ全体のテストとか
具体例
あたりを使っている



参考になりそうなプロジェクト
かなり豊富にtest書いてる