やあ、こんにちは。Reactの世界へようこそ。
フロントエンドの深淵を覗き込んでいると、時折「テストって何のためにあるんだっけ?」と迷子になることがあるよね。コードを書くのに忙しいのに、テストまで書かなきゃいけないなんて……と、頭を抱えたくなる気持ち、痛いほどよくわかります。
今日は、React Testing Library(RTL)という強力な相棒との付き合い方、特に「要素の探し方(クエリ)」について、少しだけ肩の力を抜いてお話ししようと思う。
なぜ「ユーザーの視点」が大切なのか?
まず、一番大切な心構えを共有させてほしい。
僕たちがテストを書くとき、一番やってはいけないのは「プログラムの内部構造を追いかけること」なんだ。
例えば、スーパーで買い物をする時、「この商品が棚の左から3番目の、底から2段目の箱に入っているか?」なんて考えないよね?
僕たちが気にするのは、「『りんご』という看板があるか?」「『カートに入れる』というボタンがあるか?」という、目に見える情報だけだ。
React Testing Libraryが教えてくれるのは、まさにその「ユーザーの視点」なんだ。機械的にコードの裏側を覗くのではなく、「ブラウザの前に座っている普通の人が、どうやってそのボタンを見つけるか」を模倣する。これが、テストを壊れにくくする最大の秘訣だよ。
—
クエリの優先順位:迷ったらこれを使え!
RTLにはたくさんの検索メソッドがあるけれど、実は「これを使っておけば間違いない」という優先順位が決まっているんだ。公式ドキュメントにも載っているけれど、現場の感覚を交えて解説するね。
1. `getByRole` (王道の選択肢)
これが最強にして最優先。ユーザーは「ボタン」や「見出し」といった「役割(Role)」でページを認識するからだ。
「ログインボタンを押したい」なら、`getByRole(‘button’, { name: /ログイン/i })` と書くのが一番自然なんだよ。
2. `getByLabelText` (フォーム入力の守護神)
入力フォームを探すときはこれ。ユーザーはラベルを見て入力欄を探すよね? それをそのまま再現できる。
3. `getByPlaceholderText` / `getByText` (その次点)
どうしてもRoleやLabelで取れない時に使う、いわば「最後の手段」に近いもの。
—
実際にコードで見てみよう
例えば、こんなシンプルな「ログインボタン」のテストを考えてみよう。
// コンポーネント(Login.jsx)
export function Login() {
return (
ログイン画面
);
}
// テストコード(Login.test.js)
import { render, screen } from ‘@testing-library/react’;
import { Login } from ‘./Login’;
test(‘ログインボタンが表示されていること’, () => {
render(
// 1. Role(役割)で探すのがベスト!
// 「ボタン」という役割で、「ログインする」という名前のもの。
const loginButton = screen.getByRole(‘button’, { name: /ログインする/i });
// ちゃんと存在するかチェック
expect(loginButton).toBeInTheDocument();
});
どうかな? これなら「ボタンがdivの中にあって、スタイルがどうで……」なんて考えなくていい。「ログインする」というボタンがあるか。それだけを確認すれば、テストは十分な役割を果たしているんだ。
—
getBy, queryBy, findBy の使い分け(ここが最大の難所!)
ここがみんな一番つまずくポイントだ。大丈夫、呪文を覚えるように整理すれば簡単だよ。
- `getBy…` (基本はこれ!)
- 要素が見つからないと即座にエラーを出す。「絶対にあるはず!」という強気な確認に使おう。
- `queryBy…` (「いない」ことを確認したい時)
- 要素がない時に「null」を返してくれる。例えば「エラーメッセージが表示されていないことを確認したい」といった、「存在しないこと」を証明する時に使うんだ。
- `findBy…` (非同期の魔法)
- APIからデータを取ってきてから表示されるなど、「少し待てば出てくる要素」を探すときに使う。これはPromiseを返すから、`await`を忘れずにね。
—
最後に:完璧主義を捨てよう
初学者の頃は、「網羅的にテストを書かなきゃ!」と気負いすぎてしまうもの。でも、現場のシニアエンジニアは、「ユーザーが迷いそうな重要な道筋」しかテストしていないことが多いんだ。
全部をテストしようとすると、コードを少し変えるたびにテストが壊れて、開発が嫌になってしまう。それは本末転倒だよね。
「一番大事な機能は動いてるかな?」と、ユーザーの肩越しに画面を覗き込むような気持ちで、まずはボタン一つからテストを始めてみてほしい。
もしテストが落ちても、「ああ、今はテストが僕に『そこ、ユーザーが迷うよ!』って教えてくれてるんだな」と、ポジティブに捉えてみて。
君のコードが、テストのおかげで誰よりも頑丈で、誰にとっても使いやすいものになることを、心から応援しているよ。何か詰まったら、いつでもまた聞きに来てね。大丈夫、一歩ずつ進んでいこう。

コメント