【Test】スライド「フロントエンドの書くべきだったテスト、書かなくてよかったテスト」を読んだ

@takepepeさんがイベントで話されていた以下のスライドを読んだので、ざっくりまとめておく

speakerdeck.com

書くべきだったテスト

• Router関連のテスト
  • <Link />コンポーネントの遷移先
  • searchParamsの参照
    ※query.fooが?foo=bar&foo=baz で["bar", "baz"](string[])になる可能性があるよ
• 要件が複雑な機能のテスト
• コンポーネントの肥大化を防止するテスト
  1. コンポーネントを意味のあるまとまりに分割
  2. ロジック抽出
  3. ロジックに対して単体テスト
  4. コンポーネントのテストは薄めにする
• セマンティクスの不備に気付けるテスト
  • testing-libraryを使うとgetByRoleなどのrole属性やaria属性をもとに要素を特定するので、セマンティクスの不備に気づくことができる（視覚的認知とスクリーンリーダーなどによる認知が同等であることも証明できる）
• キーボード操作の不備に気付けるテスト
  • 要件定義にないものは実装観点から落ちやすい
• ビジュアルリグレッションテスト（VRT）
  • デザインシステムの変更（特にUIトークンで変数名が変わった場合）によるリファクタリングで見た目に変更がないことをテストする

書かなくてよかったテスト

• ブラウザの自動テスト
  • Flakyになりがち
• 書くことが目的になったテスト（テスト観点がない）
• 無理にaria属性を付け足したテスト
  • 過剰なVRTはCIを遅くする（VRが発生するケースを想定する）

感想

Routerのテストは手動E2Eテストで確認しがちだが、遷移先URLがあっているかどうかなどは自動テスト化できるのでやっていきたい

Next.jsを使っている場合はnext-router-mockを使って確認ができる

next-router-mock - npm

コンポーネントのロジック抽出はどういう単位で切り出すのか、何かメンタルモデルが欲しいので深掘りしたい

UIのテストは準備するのに時間がかかるため、hygenを使って雛形を作ると良さそう

記事が公開されてた

offers.jp