Web フロントエンドのテストの種類

はじめに

複雑化する Web フロントエンドアプリケーションのテスト戦略について考えたい。その前段階として、フロントエンドのテストの種類について整理する。

フロントエンドのテストはよく 4 つの種類に分けられる。元ネタはおそらく `Learn the smart, efficient way to test any JavaScript application.`。まずはこの 4 つを整理する。

静的型システムや Linter を指す。ツールとしては TypeScript や ESLint が該当する。

インターフェースの整合性やコーディングスタイルの一貫性をチェックすることができる。アプリケーションを起動せずに静的に実行できるため素早くフィードバックループを回すことができる。

特に裏付けはないが、現代のフロントエンド開発においては TypeScript と ESLint の使用がベースラインとなっているイメージがある。

教科書的には単体のモジュールを対象としたテストとなる。何を単体と定義するかは学派が存在するほどなのでここでは言及しない。

以降に出てくるテストと比較すると実装コストが低く実行時間も短いため素早くフィードバックを回すことができる。CI でコミット単位に実行できる環境があるとよい。

複数のモジュールを組み合わせたテストとなる。

単体テストでは自分以外のモジュールをモックしてテストすることが多い。そのため他のモジュールとつないだときの動作は担保できない。統合テストではそんな単体テストではカバーできない範囲を補うテストである。

統合テストではユースケースの正常系をメインでテストし、単体テストは統合テストで網羅できない異常系や準正常系を検証できるとよい。

名前の通り、Frontend から Backend までを通したテストを指す。限りなくユーザーに近い環境でテストできるため、信頼性が高い。

一方でブラウザや DB が必要になり、セットアップに時間がかかったり、実行時間が長くなる。テストケースがカバーする範囲が広いことはメリットにもなるが、ひとつのテストケースが失敗した場合のエラー特定が困難になるなど、メンテナンスコストも高い。

テスト範囲をうまく選ぶことでアプリケーションの重要なユースケースのデグレード防止などが期待できる。

フロントエンドアプリケーションはロジック以外にも UI のスタイルや HTML の文書構造もテスト対象になる。これらには以下のテストが必要になるときもある。

見た目の変化は実際にレンダリングされないと確認するのが困難である。そのため、ブラウザでレンダリングしてその画像キャプチャを比較することで、見た目の変化をチェックするテストが必要になる。それが Visual Regression Test である。

ツールとしては reg-suit や Chromatic が有名である。しかし、コンポーネントのレンダリングとキャプチャの撮影、画像比較が必要になるため、実行時間が長くなる傾向にある。レイアウトが重要なページからテスト対象に含めるのがよい。

フロントエンドでは文書構造も重要な要素となる。ツール依存だが Testing Library を使うことで、ある程度アクセシブルなクエリを意識することができる。

Web フロントエンドアプリケーションにおけるテストの種類を整理してみた。個人的には単体テストと統合テストの境界みたいなのが説明できなかったので、ここで言語化してみた。

なにか実績があるわけではなく、あくまで頭の中を整理するためのメモである。