本当にUIテストが必要なもの
フローが端から端まで機能すること。 ユーザーが意図から結果までたどり着けるかどうか。これはインターフェースより下の層では答えられません。
ステップをまたいだ状態。 ある画面で設定した内容が、次の画面でも尊重されているかどうか。実際の不具合はここに集中します。
ユーザーに伝えられた内容が、実際に起きたことと一致していること。 レコードが保存されていないのに表示される成功メッセージは、アプリケーションがつく最もありふれた嘘です。
UIテストに含めるべきでないもの
バリデーションルール
不正な入力の組み合わせをすべてブラウザ経由で試すのは、遅いうえに壊れやすい方法です。
UIで確認するのは1つだけにして、残りはAPIで検証します。
計算処理
ユニットテストなら、ミリ秒単位で、しかもより分かりやすい失敗メッセージとともに答えを出せます。
データ準備
フィクスチャを作るために5つの画面をクリックして進むのは遅く、しかもテスト対象とは無関係な理由で壊れます。
スイートの規模を決める
有用な原則が2つあります。1つは、重要度ではなく「どれだけ静かに壊れるか」を基準にフローを網羅することです。重要なフローには人の目が届いていますが、静かに壊れるフローには届いていないからです。もう1つは、メンテナンスコストが、削減できていたはずの時間を食い始めたら追加をやめることです。その転換点は、多くのチームが思うより早く訪れます。
3つの習慣
CSSのパスではなく、安定したアンカーを使うこと。 デザイン変更による破損の大半がなくなります。
時間ではなく、状態を待つこと。 不安定さの大半がなくなります。
リロードすれば確認できることを検証すること。 成功メッセージがもたらす誤った安心感がなくなります。
テストを一つ下の層へ移す、実際の進め方
検証をインターフェースより下の層へ移すという助言は、納得はしやすいものの、実行に移すとなると漠然としています。そこで、実際の例で見てみましょう。
サインアップフォームに14通りの不正な入力を行い、そのたびにエラーメッセージを確認するブラウザテストがあるとします。実行には4分かかり、フォームのレイアウトが変わるたびに壊れ、そしてブラウザについてはほとんど何も教えてくれません。
これを、不正な入力を1つ送信してユーザーにエラーが表示されることを確認するブラウザテスト1件と、バリデーションルールを直接検証するAPIテスト13件に置き換えます。こうすればブラウザテストはブラウザに関する問いに答えるものになり、ルールはより速く、より正確に網羅され、バリデーションを変更しても描画に関わる部分に手を入れる必要はなくなります。
規律では解決できない部分
セレクター
機能的には何も変わらないデザイン変更でも、スイートは赤くなります。
メンテナンス時間の大半が実際に費やされているのは、ここです。
待機処理
固定の待ち時間は遅く、それでいて不安定なままです。正しく待つには、何を待つべきかを知る必要があります。
不安定さの大半は、ここに行き着きます。
人が書いたカバレッジ
網羅できるのは誰かが書いた範囲だけであり、それは実際に壊れるフローではなく、目を引くフローです。
3つ目は構造的な問題です。書き手の時間に制約されたカバレッジは、コードがますますエージェントから生み出されるようになった製品には追いつけません。意図ベースのステップと自動生成されたカバレッジが、この部分に対応します。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルにインストールしたくない場合は、ダッシュボードでも同じ範囲をカバーできます。また、コマンドの全体像が収められているのが CLIリポジトリです。
ダッシュボードからリポジトリを接続すれば、すでに実施しているデプロイを起点にテストの実行が始まります。あるいは、自前のワークフローにステップを追加する方法もあります。
TestSpriteが各層でカバーする範囲
ブラウザでしか答えられない問いはブラウザ上のフローとして扱い、その下のAPI層も同じプロジェクト内で扱います。これにより、「下の層へ移す」という助言は理想論ではなく、実践可能なものになります。バリデーションルールは数秒で実行できるAPIのテストケースへ移り、ブラウザのテストケース1件が、フォームがそのルールと正しくつながっていることを確認します。
どちらも製品から自動生成され、平易な言葉で調整できます。さらにブラウザのステップはセレクターではなく意図として表現されるため、機能に影響しないデザイン変更があってもスイートは生き残ります。
結果として手元に残るのは、メンバーが信頼できる程度に小さく、重要なジャーニーを押さえたブラウザテストのスイートです。ルールやエッジケースは、一つ下の層でより速く網羅されます。
UIテストは何件が適切ですか?
壊れたら恥ずかしいと感じるジャーニーを網羅できるだけの数です。選ぶ基準は、どれだけ静かに壊れるかです。それ以外はすべて一つ下の層へ移しましょう。
すべての画面をテストすべきですか?
いいえ。テストすべきは画面ではなくフローです。フローが通らない画面に、ブラウザテストを用意する理由はほとんどありません。
アクセシビリティはどうですか?
機械的にチェックできる部分は自動化する価値があり、それ以外は人によるレビューが必要です。専用のツールを持つ、別の関心事です。
クロスブラウザでの網羅は必要ですか?
アクセス解析のデータ次第です。多くのチームは1つのブラウザでフルスイートを実行し、他のブラウザではスモークテストのみを実行しています。たいていはこれが妥当な落としどころです。
UIテストはいつ実行すべきですか?
プルリクエストごとに実行します。それより頻度が下がると、失敗が指し示すのは1つの変更ではなく、変更のまとまりになってしまいます。