テストコード、どこに何書く
業務でWebフロントエンドのテストコードを書く際に、どこに何を書くかというのをざっくりと考えをまとめてみます。
前提
Webアプリケーションのプログラムファイルがツリー構造である前提とします。
よくあるフィーチャー単位のフォルダ構成っぽいものを例として出すと、
- repo/
- page.tsx
- A: BのハンドラやデータをCに渡す
- B: 外部連動するファイル（APIフェッチ・ミューテーション、リダイレクトなど）
- C: UIコンポーネント: HTMLの定義場、Dを使って振る舞う
- D: 振る舞いファイル
- E: フォームバリデーションファイルなど
- D: 振る舞いファイル
- A: BのハンドラやデータをCに渡す
- page.tsx
1つのプログラムファイルは何をしているか
1つのプログラムファイルに書かれていることを読み、
そこにあるロジックを基本的にテストコードに落とし込みます。
書かれていることはホワイトに、読み込まれているものはブラックにやります。
単体
BやEは誰も参照しない単体で、ホワイトなテストをします。
境界値や組み合わせ、条件分岐、事細かく検証します。
ここで徹底して検証することで、使用する側への検証負担を軽減させます。
Dは、Cから読み込まれてEを読み込むファイル。
個人的経験則で、DはCのためのprivateなモノという認識で、
CのテストでDの内容が内包されるイメージ。
ユーザー視点の振る舞いで検証を書くため。
ただし、Dのロジックが複雑でCのテストで書くのが困難なら、D単体のテストを書く。
結合
Cは、Aからデータや更新ハンドラを貰ってDの振る舞いを使ってUIを構築する結合部分。
Cから見て、Eのこと細かい検証は書かずブラックボックスとする。
データに応じたHTMLの表示検証や、マウスやキーボード操作による振る舞いの検証をここで行う。
実際にAPIを実行するものではなく、そこは与えられたデータ・ハンドラを使用する前提にする。
Eの詳細は行わないが、正常・失敗の2分岐ぐらいはCのテストに含める。（Cのロジックによる）
UIには状態遷移がよくあるので状態遷移による検証は網羅して行うと、仕様の不備に気付けることがある。
Aは、Bでフェッチしたデータやデータ更新ハンドラをCのUIに渡す橋渡しする結合部分。
データによってはUIを変えたり、ローディング状態を表示したりもする。
Bの中身の詳細には触れず、返ってくる前提のデータやハンドラをモック・スパイ等で置き換えつつ、
データに応じたUIチェックや、クリックアクション時にハンドラ実行されているか、の検証になる。
全部結合
それぞれのファイルには、それぞれの前後関係による結合や単体のテストコードを書きますが、
上から下まで全て結合したテストができていません。
API データフェッチが実はうまくいっていなかったり更新できなかったり、偽物でテストしていたモノを確認する必要があります。
所謂E2Eテストを書くのは、そういうポイントの検証をする側面があります。
E2Eテストには、これまでの結合・単体よりも幅広く検証できてしまう面と不安定さが生んでしまう面があるため、
単体・結合で行っていたことは基本的に行わず、正常・準異常系・異常系、クリティカルパス、ハッピーパスなどの区分などで書くことが多いです。
コスパ
全部が全部テストコードを書いてられるかと言われると、時間は有限です。
コスパの良いものを優先的にやるのが良いでしょう。
アプリでバグりやすい箇所を優先的にテストがあると良心的と思うので、
バグりやすいかどうかは機械的な仕組み（循環的複雑度とかソースコードホットスポット）でも良いし、
ドメイン部分の観点（データ依存の複雑さ、ビジネスロジックの複雑さ）でも良さそうです。
バグりやすいではなくて、バグったらビジネス的にマズいところを優先するのも、手ですね。
決済とかお金が絡むところとか、コンバージョンに達するところとか。
非機能
純粋に書かれている機能面の検証だけでなくて、
別軸で非機能面の検証が必要です。
Webフロントエンドだと、ブラウザパフォーマンス、アクセシビリティ、データ増減等によるレスポンシブ、セキュリティなどもチェックすることもあります。
それぞれも、テストコードに落とし込めますが、割愛します。
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「テスト」の記事
個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。 期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。 そのテストコードは、プロダクションコードをそのままテストコー
最近、Testcontainers を使う機会があり、苦労したことについて備忘録として残しておきます。 前提 以下の記事で書いてある構成に近いものです。 https://zenn.dev/silverbirder/articles/0a54
2026年05月14日
以下の記事で書いた CSSをテストする方法について、試してみました。 https://zenn.dev/silverbirder/articles/df6752b230f04c ソースコードは、以下に置いています。 https://gith