UI自動テスト:壊れても気づかれない箇所から選ぶ

UI自動テストのより良い選定基準

フローの優先順位は、重要度ではなく、壊れたときにどれだけ長く気づかれないままかで決めます。エクスポート、招待、設定画面、定期配信のダイジェスト。どれも誰かにとっては重要ですが、大勢が見ているわけではありません。だからリグレッションが1か月そのまま放置されるのです。

2つ目の基準は、そのフローがどれくらいの頻度で変わるかです。スプリントごとに作り直される画面は、得られる価値よりも保守コストのほうが大きくなります。仕様が落ち着いてからカバーしてください。

3つのコスト

最初の2つは、規律を持って取り組めば対処できます。3つ目は構造的な問題です。人が書くカバレッジは書き手の時間に縛られ、その時間は増えないからです。

効果の大きい3つの習慣

• 安定した属性を基準にする。 CSSのパスではなく、テスト専用の属性を使います。これだけで、デザイン変更による破損の大半がなくなります。

• 時間ではなく、状態を待つ。 要素やレスポンスを待ちます。固定の待ち時間は、遅いうえに信頼できません。

• 再読み込みしても確認できることを検証する。 成功のトースト表示は、データが保存された証拠にはなりません。

スイートが捨てられる理由

何も検出しないからではありません。本当の不具合と保守起因の失敗の比率が悪化し、誰も結果を読まなくなるからです。ビルドが赤いことが「おそらくバグ」ではなく「おそらくセレクタ」を意味するようになった時点で、そのスイートは動き続けていても、すでに機能していません。

本当に取り組むべき仕事はこの比率を守ることであり、それはテストの数よりも、手順をどう表現するかにかかっています。

書き手の時間に依存しないカバレッジ

意図として表現された手順は、見た目だけの変更に耐えます。そして、誰かの記憶ではなくプロダクトから生成されたカバレッジには、誰も書こうとしなかったフローが含まれます。それこそが、規律では解決できないコストの部分です。

ローカルにインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドの全体像がまとまっているのは CLIリポジトリです。

有用であり続けるスイートの規模

ブラウザテストのスイートには、それを超えると得られる価値よりコストのほうが大きくなる規模があり、それは多くのチームが想像するよりも小さいものです。

制約になるのは実行時間ではなく、注意力です。30のフローからなるスイートなら、失敗したときに誰かが原因を調べます。300のフローからなるスイートが生み出すのは日々のリストであり、リストは読まれるのではなく仕分けされます。仕分けが始まったら、追加した1本のテストがどれだけよく書かれていても、それはカバレッジではなくノイズを増やしているだけです。

ですから、テストを追加するときに問うべきなのは、そのフローが重要かどうかではありません。金曜の午後にこのテストが失敗したとして、自分は原因を調べるだろうか、ということです。正直なところ再実行して先に進むだけだと答えるなら、そのテストはすでにノイズであり、書くことでスイートは悪くなります。

変更のたびに実行する

重要なのは仕組みよりもトリガーです。デプロイのイベントに紐づけておけば、誰かがそのつど判断しなくても、すべての変更がチェックされます。 GitHub App はダッシュボードからそれを実現し、 GitHub Actions のステップはワークフローの内側から同じことを行います。

TestSpriteが計算を変える部分

3つ目のコスト、つまり書き手の時間に縛られるカバレッジは、規律では解決できないものであり、TestSpriteが取り除くのはここです。テストケースはプロダクトから生成され、自然な言葉で調整できます。そのため、誰かが午後の時間を割いて書かなくても、静かなフローがカバーされます。

最初の2つのコストは、その副作用として改善します。手順はDOM上のパスではなく意図として保存されるため、ボタンの位置が変わるデザイン変更でスイートが赤くなることはありません。待機も、テストごとに調整するのではなく自動的に処理されます。保守時間の大半を占めているのは、この2つです。

これによって守られるのは、スイートが生き残るかどうかを決める数字、すなわち赤いビルドのうち本当のバグである割合です。この割合を高く保てば、人は結果を読み続けます。それが、カバレッジと、毎晩走るだけのジョブとの違いです。