「スタブ」「スパイ」とは、モック（テストダブル）をそれぞれの目的に応じて分類したオブジェクトの呼称。（Gerard Meszaros氏の著書『xUnit Test Patterns: Refactoring Test Code』を引用とのこと）
スタブの目的
「代用」を行うこと。
依存コンポーネントの代用品
定められた値を返却するもの
テスト対象に「入力」を与えるためのもの
スタブは、テスト対象が依存しているコンポーネントに、何らかの不都合がある場合に使用する。
例えば、Web APIに依存しているテスト対象を検証するとき。「Web APIからこんな値が返ってきた場合、このように動作する」というテストでスタブを使用する。テスト対象がスタブにアクセスすると、スタブは定められた値を返却する。
スパイの目的
「記録」を行うこと。
関数やメソッドの呼び出しを記録するオブジェクト
呼び出された回数、実行時引数を記録するもの
テスト対象からの「出力」を確認するためのもの
スパイは、テスト対象から外側に向けた出力の検証に利用する。
例えば、関数引数のコールバック関数。コールバック関数が実行された「回数」「実行時引数」を記録しているので、意図通りの呼び出しが行われたかを検証できる。
Jestにおける用語の混乱
スタブ、スパイの実装は、モックモジュール（jest.mock）やモック関数（jest.fn、jest.spyOn）というAPIを使用する。
これらを使用したテスト向けの代用実装を「モック」と呼んでいるケースが多い。
UIコンポーネントテスト
UIコンポーネントテストに求められる基本機能
データを表示すること
ユーザ操作内容を伝搬すること
関連するWeb APIを繋ぐこと
データを動的に書き換えること
Testing Library
主な役割
UIコンポーネントをレンダリングする
レンダリングした要素から、任意の子要素を取得する
レンダリングした要素に、インタラクションを与える
UIコンポーネントテスト用のマッチャー拡張
DOMの状態を検証するためにはJest標準のマッチャーだけでは不十分。
@testing-library/jest-domはDOMの状態を検証するために導入する。
ユーザ操作をシミュレートするライブラリ
Testing Libraryには文字入力などを行うためのfireEventというAPIが提供されている。しかし、このAPIはDOMイベントを発火させるだけのものなので実際のユーザ操作では不可能な操作もできてしまう。
そこで、実際のユーザ操作に近いシミュレートができる@testing-library/user-eventを導入する。
クエリー（要素取得API）の優先順位
誰でもアクセスできるクエリー
心身特性に隔たりのない体験に基づくクエリー。
視覚的認知とスクリーンリーダーなどによる認知が同等であることが証明できる。
getByRole
getByLabelText
getByPlaceholderText
getByText
getByDisplayValue
セマンティッククエリー
標準仕様に則った属性に基づくクエリー。
これらの属性に基づく体験はブラウザや支援技術によって大きく異なることに注意が必要。
getByAltText
getByTitle
テストID
getByTestId
formのアクセシビリティ
aria-labelledby属性にh2要素のIDを指定することでアクセシブルネームとして引用させることが可能。
React18で追加されたuseIdフックを使うことでアクセシビリティ観点で必要なid値の自動生成、自動管理が可能。
アクセシブルネームを与えないとform要素はformロールを持たない。