テストは通ったのに、なぜ画面は使いにくい？

一言でいうと

型チェック、React DOMの動作検査、実際のブラウザでの検査は、それぞれ別の問いに答えます。検査結果を伝えるときは、何を観察したのかまで一緒に説明します。

なぜ必要なのか

クジラの検索が最後まで維持され、すべての状態検査が通りました。ところが、スマートフォンでは検索ボタンが画面の外にあり、キーボードで入力している途中でレスポンスが届くと、フォーカスが結果領域に移動します。実装者はテストがグリーンだと言い、ユーザーは依然として使えないと言います。どちらかが嘘をついているのではなく、互いに別の対象を見ている場合です。

このコースは、検査の範囲を分けます。学習者のソースは、型チェックのあと実際のReactでDOM環境にレンダリングし、リクエストの前後の状態を読みます。DOM環境はブラウザの一部のAPIを実装していますが、文字の配置や実際のペイントコストを再現するレイアウトエンジンではありません。画面幅やパフォーマンスをその結果だけで判定すると、根拠のない確信になります。

どう動くのか

検査する動作を、小さな出来事に分けましょう。コンポーネントをレンダリングし、検索を提出し、指定したレスポンスを完了させ、Reactの更新が反映されたあとでDOMを読みます。Reactの非同期actは、その境界を扱うときに使うツールです。適当に3秒眠る方式は、速いコンピューターでは時間を無駄にするだけで、遅い環境では依然として先に読んでしまうことがあります。

検査の層	確認する例	これだけではわからないこと
TypeScript	状態ごとの必須データと型	実際のレスポンスの到着順
React+DOM	逆順のレスポンスのあとの結果、エフェクトのクリーンアップ	ピクセルの配置とペイントコスト
実際のブラウザ	キーボード操作の経路、狭い画面、レンダリングの記録	すべての支援技術での使いやすさ
ユーザー観察	指示文を理解して課題を終えられるか	ほかのすべてのユーザーの体験

アクセシビリティでは、入力の名前、実際のform送信、結果の変更の案内、フォーカスの維持がつながります。新しい結果を知らせることと、結果にフォーカスを強制的に移すことは別です。ユーザーが検索語を直し続けている途中なら、現在の入力位置を保ったまま、変更を伝える必要があります。自動検査の通過を、スクリーンリーダーでの使いやすさの認証と表現してはいけません。

パフォーマンスも、時間を分けて見ます。リクエストを送ってからレスポンスを受け取るまでの待ち時間と、結果をReactで計算して画面に描くコストは別のものです。ネットワークの待ち時間だけが長いのにmemoを付けても、レスポンスは速く届きません。すでに結果が届いているのに、1万行を一度に表示するコストが大きいなら、ネットワークの再試行では解決しません。

React Profilerのレンダリング時間と、ブラウザのレイアウト・ペイント・ネットワークの記録を、同じ数字として扱わないようにしましょう。測定の前に、データ数、開発/本番ビルド、デバイス、繰り返し回数を記録します。1回だけの良い数字よりも、同じ条件での複数の観察のほうが役に立ちます。この段階では、目標の数字に合わせるために観察値をでっち上げません。

観察記録の残し方

良い記録は、結果の数字だけを書いた表よりも、再現条件を先に伝えてくれます。次の様式に、実際にやったことだけを記入してみましょう。まだ実行していない項目は、空欄をもっともらしい値で埋めず、未確認として残します。

項目	記録する内容
対象	ソースのバージョン、変更した関数、ビルドの種類
環境	ブラウザのバージョン、画面幅、デバイスの条件
入力	データ件数、検索語、提出・レスポンスの順序
期待	最後に残るべき結果とフォーカスの位置
観察	実際の結果、エラー、レンダリングまたはネットワークの記録
残りの範囲	ほかの画面・支援技術・実際のサービスとの接続

たとえば、クジラの次に猫を配信したという記録だけでは不十分です。リクエストをどの順序で送ったのか、キャンセルを無視するモードだったのか、最新の結果を確認してから過去のレスポンスを配信したのかが必要です。こうした条件が抜けると、同僚は同じコードを受け取っても、問題を再現できません。

パフォーマンス改善の前後でも、一度に1つの条件だけを変えるほうが、解釈しやすくなります。表示する行数とネットワークの遅延とビルドの種類を同時に変えると、どの変更が効果を出したのかがわかりにくくなります。表示件数を減らしたなら、総結果数と現在の表示数をユーザーに伝えて、データが失われたと誤解されないようにする必要があります。速く見せるために結果を黙って捨てることは、パフォーマンス改善とは別の、製品の変更です。

現場での姿

顧客に障害修正の結果を説明するときにも、同じ原則が当てはまります。「テスト通過」の代わりに、「逆順の成功・失敗と、破棄時のキャンセルは再現して確認しましたが、モバイルの実際のセッションはまだ確認していません」と言えば、次のレビュー対象がはっきりします。確認していない範囲を明らかにすることが、検査への信頼を高めます。

採点ツールも、検証の対象です。正解のほかに、無条件でsuccessを返すコード、途中でexitするコード、終わらないコードを入れてみます。終了コード0やstdoutのPASSという文言だけを信じると、学習者のコードが検査をたまたま飛ばしても、通過してしまいかねません。採点結果が最後まで収集されたかと、学習者の元のファイルが変更されていないかも確認します。

自分で確認すること

DOM検査と実際のブラウザでの観察を、別々に記録します。どの検査がどの欠陥を捕まえたのかを表に整理し、まだ観察していない範囲を残します。長い一覧の実測は実際のブラウザで行い、DOMモデルで得た時間を代わりに提出しないでください。

ツールの範囲は、React act、React Profiler、jsdomの案内を参照してください。