はじめに
ランディングページを対象に、Lighthouse、スモークテスト、Playwright による E2E テストについて考えてきました。
しかし、これだけでは次の疑問が残ります。
なぜ、そのテストを選んだのか。
なぜ、最初にユニットテストを書かなかったのか。
この記事では、テスティングトロフィーの考え方をもとに、ランディングページにおけるテストの優先順位を整理します。
結論から言うと、ユニットテストを書かなかったのは、ユニットテストが不要だからではありません。
今回のランディングページで最初に減らすべき不安が、関数単位のロジックではなく、公開ページとしてユーザーが行動できるかどうか だったからです。
テストは「手法」ではなく「不安」から考える
テストを考えるとき、いきなり「ユニットテストを書くべきか」「E2E テストを書くべきか」から始めると判断が難しくなります。
先に考えるべきなのは、次の問いです。
このページで、壊れたら一番困るものは何か。
ランディングページで困るのは、たとえば次のような状態です。
- ページが表示されない
- CTA ボタンが押せない
- 問い合わせフォームに進めない
- スマホ表示で大きく崩れている
- 外部リンクが間違っている
- 表示速度やアクセシビリティに大きな問題がある
これらは、コードの内部構造だけを見ても判断しにくい問題です。
ランディングページでは、HTML、CSS、JavaScript、画像、フォーム、外部リンク、レスポンシブ表示などが組み合わさって、ユーザー体験が成立します。
そのため、まず考えるべきなのは、どのテスト手法が正しいかではなく、どの不安を先に減らすか です。
テストピラミッドとテスティングトロフィー
テストの考え方として、よく テストピラミッド が紹介されます。
UIテスト
結合テスト
ユニットテスト
これは、ユニットテストを多く書き、UI に近いテストは少なくする考え方です。
サーバーサイドでは、この考え方が有効に働きやすいです。計算、バリデーション、データ変換、状態遷移などを関数やクラスに切り出しやすいからです。
一方で、フロントエンド、とくにランディングページでは、単純に「まずユニットテストを厚く書く」とは言いにくい場合があります。
LPで重要なのは、関数単位の正しさだけではありません。
- ブラウザで正しく表示されるか
- ユーザーがCTAを押せるか
- フォームや購入導線に進めるか
- スマホで操作できるか
- ページ品質が最低ラインを満たしているか
といった、ユーザーに近い確認が重要になります。
そこで参考になるのが テスティングトロフィー の考え方です。
テスティングトロフィーは、ユニットテスト不要論ではありません。
ユーザーに近い信頼性と、テストの保守コストのバランスを考えるためのモデルです。
ランディングページ向けに読み替えると、次のようになります。
E2Eテスト
重要なユーザー導線が最後まで動くか
スモークテスト
公開ページとして致命的に壊れていないか
Lighthouse
速度・アクセシビリティ・SEOなどの最低品質を満たすか
ユニットテスト
独立したロジックを小さく検証する必要があるか
ランディングページで最初に守るべきもの
ランディングページの目的は、多くの場合、ユーザーに何らかの行動をしてもらうことです。
たとえば、
- 問い合わせする
- 資料請求する
- 商品を購入する
- 予約する
- 外部サービスへ遷移する
といった行動です。
そのため、最初に守るべきものは、コードの内部構造というよりも、ユーザーが目的の行動に進めること です。
| 減らしたい不安 | 向いている確認 |
|---|---|
| ページ品質が低くないか | Lighthouse |
| 公開ページとして致命的に壊れていないか | スモークテスト |
| CTAやフォーム導線が動くか | Playwright E2E |
| JSの計算や条件分岐が正しいか | ユニットテスト |
Lighthouse、スモークテスト、E2E は、競合する道具ではありません。
それぞれ、違う不安を減らすための道具です。
なぜ最初にユニットテストを書かなかったのか
理由は、主に3つあります。
複雑なロジックが少ないから
ユニットテストが効果を発揮しやすいのは、入力と出力がはっきりしている処理です。
たとえば、料金計算、日付判定、フォームバリデーション、データ変換などです。
しかし、シンプルなランディングページでは、JavaScript の役割が次のような処理に限られることがあります。
- メニューを開く
- CTA までスクロールする
- モーダルを開く
- 外部フォームへ遷移する
これらは重要ですが、関数の戻り値だけを確認しても、ユーザーが実際に操作できるかまでは保証しにくいです。
不具合がブラウザ上で起きやすいから
LPの不具合は、JavaScript の関数だけで起きるとは限りません。
たとえば CTA ボタンひとつでも、次のような壊れ方があります。
- CSS の影響で見えない
-
z-indexの影響でクリックできない - リンク先URLが間違っている
- スマホ表示で画面外に出ている
- 外部フォーム側のURLが変わっている
このような問題は、ユニットテストだけでは見つけにくいです。
ブラウザ上で表示し、クリックし、導線を確認するほうが自然です。
ユーザー導線のほうが事業影響が大きいから
ランディングページで一番困るのは、ユーザーが行動できないことです。
たとえば、
トップページを開く
↓
CTA をクリックする
↓
問い合わせフォームに進む
↓
確認画面またはサンクスページに進む
この導線が壊れていると、問い合わせや購入に直結します。
そのため、最初はユニットテストをたくさん書くより、重要な導線を少数の E2E テストで守るほうが効果的な場合があります。
それでもユニットテストを書く価値がある課題
もちろん、ユニットテストが不要という意味ではありません。
ユニットテストを書く価値があるのは、入力と出力がはっきりしていて、ブラウザを開かなくても正しさを確認できる処理 です。
たとえば、次のような処理です。
| 課題 | ユニットテストを書く価値 |
|---|---|
| 料金計算 | 計算ミスが信頼に直結する |
| キャンペーン期間判定 | 日付の境界条件を確認しやすい |
| フォームバリデーション | 入力パターンを確認しやすい |
| UTMパラメータ処理 | 広告計測に影響する |
| A/Bテストの振り分け | 条件分岐が複雑になりやすい |
| APIレスポンスの整形 | データ変換の正しさを確認できる |
たとえば、次のような処理はユニットテストに向いています。
function isCampaignActive(today, startDate, endDate) {
return startDate <= today && today <= endDate
}
このような関数は、入力と期待結果がはっきりしています。
test('キャンペーン期間内なら true を返す', () => {
expect(
isCampaignActive(
new Date('2026-07-10'),
new Date('2026-07-01'),
new Date('2026-07-31')
)
).toBe(true)
})
この場合、ブラウザを開いて確認するより、ユニットテストで小さく確認したほうが速く、原因も特定しやすいです。
つまり、ユニットテストは ロジックがあるところに書く と考えるとわかりやすいです。
LP向けのテスト優先順位
ランディングページでは、次の順番で考えると現実的です。
1. Lighthouse で最低品質を見る
表示速度、アクセシビリティ、SEO、ベストプラクティスの大きな問題を確認します。
2. スモークテストで致命傷を確認する
ページが開けるか、CTA が見えるか、フォームに進めるか、スマホ表示で大きく崩れていないかを確認します。
3. Playwright で重要導線を1本だけ自動化する
問い合わせや購入など、成果に直結する導線を少数だけ E2E テストで守ります。
4. 複雑なロジックが出てきたらユニットテストを追加する
料金計算、日付判定、入力検証、API連携などが出てきたら、ユニットテストを書く価値が高くなります。
まとめ
ランディングページのテストで、最初にユニットテストを書かなかったのは、ユニットテストを軽視したからではありません。
今回のLPで最初に減らすべき不安が、関数単位のロジックではなく、公開ページとしてユーザーが行動できるかどうかだったからです。
整理すると、次のようになります。
| 減らしたい不安 | 優先する確認 |
|---|---|
| ページ品質が低くないか | Lighthouse |
| 公開ページとして致命的に壊れていないか | スモークテスト |
| ユーザーがCV導線を進めるか | Playwright E2E |
| JSの計算や分岐が正しいか | ユニットテスト |
テストを書くこと自体が目的ではありません。
大事なのは、壊れたら困るものを見極め、その不安を減らすために、ちょうどよいテストを選ぶことです。