イントロ

adbentoカレンダー　９日目です。

フロントエンドを実装するにあたって意外と難しいのがテストの設計ではないでしょうか？
何を保証し、どう設計するか？
フロントエンドは、ユニットテストとは違うアプローチが多々必要です。

ここら辺のテストの話を毎回してる気がするのでメモがてら書いていきます。

対象者

この記事は、フロントエンドの種類を把握してる人むけに書いてます。
従って、本記事で出てくるテスト手法やツールの詳しい説明は割愛します。

興味がある方は以下の記事などを見てください。

フロントエンドのテストはなぜ難しい?

結論から言えば、曖昧なものを保証しないといけないからです。

バックエンドの最終的な出力はデータなのでそれを検証してテストします。
例えば、以下のような関数がある場合、返り値が2であることを保証すれば良いです。

function two() {
    return 1 + 1
}
assert(tow(),2)

しかしフロントのアウトプットは以下の様な画面です。

画面を構成する要素はCSSはDOM,JSが絡み合っておりとても複雑です。
そのため、完全に正しい画面を保証する場合、テストの種類と量が爆発的に増えてしまいます。

この"正しさ"をROIと勘案しテスト設計を行うがフロントエンドのテストの難しさです。

何をテスト対象にするべきか？

フロントエンドの意義はユーザーとシステムを繋ぐインターフェースです。

従って、ユーザーに動作とその結果の表示を検証できれば良いと思います。

フォームを入力する　 -> ボタンが活性化する。
フォームに3000文字以上入れる -> エラーメッセージを出す。

下記のように、機能を発火させる要素とその結果の変化を観測できれば良いです。
従って、以下のような機能発火のトリガー要素はテスト対象に含めましょう。

ボタン
- 活性
- テキスト
エラー
- エラーモーダル
- エラーテキスト
デザイン
- デザイン崩れがないか？

手法は何を使うべき？

テストトロフィーに習うと、
インテグレーションテストを厚く書きましょう。

具体的には、以下の2種類で良いと思います。

componentテスト

react-testing-libaryなど、コンポーネントに対してのテストです。
ユーザーを誘導する要素を検証数ためのテストです。

詳しい内容はこちらを参照

visual regression test.

意図したデザインを保証するためのテストです。

仕組みは非常にシンプルで、変更前と変更後の画像を比較して、その差分を表示してくれます。
よく使われるのは、githubのCIに仕込んでおき、PRと一緒に下記のような画像で変更をチェックする運用です。

下記の画像ですと、紫の部分が変更した差分となります。

引用: https://tech.dely.jp/entry/vis_reg_test

画面の正しさは数式の正しさではなく、人間の主観的な正しさなので、デザイン崩れは、コードベースのテストでは防げません、
従って、人間が目視でチェックするかしかありません。

VRTはこの目視チェックの工程を統一的に表示して補助してくれます。
入れておくことに損はないと思います。
　

何から始めるべきか？

ユーザーストーリーの整理から始めましょう。

どこから始まるのか？
どこで終わるのか？
何が目的か？
どんな操作をするのか？
- トリガー -> 結果

上記のように、ユーザーが目的を達するための利用ストーリーを時系列順に書き出しましょう。

グーグル検索であれば

どこから始まるのか？
- 検索画面
どこで終わるのか？
- 情報が存在するサイト
何が目的か？
- 自分が欲しい情報へ辿り着く
どんな操作をするのか？
- 検索フォームに調べたい情報のキーワードを入力
- 検索結果をクリックして情報がありそうなサイトへ訪問する

このストーリーであれば、下記の情報が得られます。

検索フォームが動かないのは致命的なのでテストを書こう
複数のサイトを訪問する可能性があるので、検索結果の表示のスピードは計測したほうがいいかも？

このように、

致命的ケースは何か？
ユーザー体験関わる部分は何か？

などを掘り下げながらテストを構築しましょう。

最後に

必ずしもテストを書くことが正義とは限りません。
プロダクトや、事業フェーズに応じて、テストの比重は変わります。

そこを勘案しながら設計していきましょう。

それではよきテストライフを

フロントエンドは見えるものをテストしよう