テストを書いて、
自動で回す。

そもそも「テスト」とは

ここでいうテストとは、テスト用紙のことではありません。「あなたのサイトやプログラムが、思ったとおりに動くかどうかを、自動でチェックしてくれる小さなプログラム」のことです。テストコードとも呼びます。

たとえば、お問い合わせフォームを作ったとします。テストは、「名前とメールを入れて送信したら、ちゃんと“ありがとうございました”と表示されるか？」を、人間の代わりに何度でも確認してくれます。「こう操作したら、こうなるはず」という“約束”を文章にしておき、その約束が守られているかを機械が判定する——それがテストの正体です。

なぜ、わざわざテストを書くのか

「動いているんだから、いちいちテストなんて要らないのでは？」と感じるかもしれません。テストの本当のありがたみは、サイトを“直したとき”に出てきます。

サイトは一度作って終わりではなく、何度も手を入れて育てていくものでしたね。ところが——あるページを直したら、まったく別のページが知らないうちに壊れていた。これは開発で本当によく起こります。これを「デグレ（後戻り）」と呼びます。人間がすべてのページを毎回手で確認するのは、現実的ではありません。見落とします。

そこでテストです。一度テストを書いておけば、どこかを直すたびに「他のところも全部、まだ大丈夫か」を一瞬でまとめて確認できます。これが、テストを書くいちばんの理由です。直すのが怖くなくなる——つまり、安心して育て続けられるようになるのです。

「自動で回す」が、いちばん大事

テストを書いても、実行するのを忘れたら意味がありません。「急いでいたから、今回は確認せずに公開しちゃった」——その一回で事故は起きます。人間は、忙しいと必ずチェックを飛ばします。

だから、テストは「人が思い出して実行する」のではなく、「仕組みが勝手に実行する」形にします。具体的には、前章で学んだ GitHub Actions を使い、GitHub に push するたびに、自動でテストを全部走らせるようにします。テストが通らなければ、公開を止めることもできます。

これで、流れはこうなります——直す → push → 自動でテストが走る → 全部OKなら自動で公開。壊れたものは、世界に出る前に止まる。これが、テストと CI/CD を組み合わせた「安心して回せる開発」の形です。

どんなテストを書けばいい？

最初から完璧を目指さなくて大丈夫です。「壊れたら困る、大事なところ」から1つずつ書いていきます。たとえば、こんな観点です。

1. 大事な機能は動くか：問い合わせフォームが送信できる、予約ボタンが反応する、など。
2. 正しい結果が返るか：合計金額の計算が合っている、入力チェックがちゃんと弾く、など。
3. ページが正しく表示されるか：トップページがエラーにならず開ける、必要な見出しが出ている、など。

「うちのサイトで、絶対に壊れてほしくないのはどこか？」——その問いの答えが、最初に書くべきテストです。

① Claude Code にテストを書いてもらう

テストコードも、自分でゼロから書く必要はありません。Claude Code にお願いするのが正解です。何を確認したいかを日本語で伝えれば、その言語・仕組みに合ったテストを書いてくれます。

このサイトのお問い合わせフォームについて、テストを書いてください。
・名前・メール・本文を入力して送信すると「ありがとうございました」と表示されること
・メールアドレスが空のまま送信すると、エラーメッセージが出ること
このプロジェクトに合ったテストの仕組み（テスト用のライブラリ）も、必要なら一緒に導入して、実行のしかたも教えてください。

「テスト用のライブラリ」とは、テストを動かすための道具のことです（よく使われるものに Jest や Vitest、ブラウザ操作まで試す Playwright などがあります）。どれを使うべきかも含めて、Claude がプロジェクトに合わせて選んでくれます。名前を覚える必要はありません。

② 手元でテストを実行してみる

テストが用意できたら、まずは自分のパソコンで走らせてみます。多くのプロジェクトでは、次のような短いコマンドで実行できます（具体的なコマンドは Claude が教えてくれます）。

npm test

実行すると、テストの結果が緑（成功）／赤（失敗）で表示されます。緑がずらりと並べば、確認したかったことが全部OKという意味。赤が出たら、そこが「約束どおりに動いていない」場所です。

③ push のたびに、自動でテストを回す

いよいよ本題、自動化です。前章と同じ GitHub Actions を使い、push されたら自動でテストを走らせる命令書（ワークフロー）を置きます。場所も同じ、.github/workflows/ の中です。

name: Run tests

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

ざっくり読むと——「push されたら（on: push）、作業machineを用意し、必要な道具を入れて（npm install）、テストを実行する（npm test）」という命令書です。これも、自分で書かずに Claude に頼むのが確実です。

mainブランチへのpushとプルリクエストのたびに、このプロジェクトのテストを自動で実行するGitHub Actionsのワークフローを作ってください。.github/workflows/test.yml として作成し、各ステップの意味も初心者向けに説明してください。

これを push して登録すれば完成です。以降は GitHub の「Actions」タブで、push のたびにテストが自動で走り、緑か赤かが記録されていきます。

仕上げ — テストが通ったときだけ公開する

ここまで来たら、最後のひと工夫です。「テストが全部通ったときだけ、自動で公開する」ようにつなげば、壊れたものが本番に出ることを仕組みで防げます。公開（デプロイ）や FTP自動公開と、このテストを組み合わせるわけです。

テストが全部成功したときだけ、自動で公開（デプロイ）が実行されるように、GitHub Actionsのワークフローをつなげてください。テストが1つでも失敗したら、公開は止めるようにしてください。

これで、直す → push → 自動でテスト → 全部OKなら自動で公開という、安心の流れが完成します。ここまでが、プロの現場でも使われている「テスト付きの自動公開」の基本形です。

この章で出てきた言葉

テスト / テストコード

「こう操作したら、こうなるはず」を確認してくれる小さなプログラム。動作確認を自動化します。

デグレ（後戻り）

あるところを直したら、別のところが知らないうちに壊れること。テストが防いでくれます。

テストライブラリ

テストを書いて動かすための道具。Jest・Vitest・Playwright など。Claude が選んでくれます。

npm test

多くのプロジェクトでテストを実行する標準的なコマンド。結果が緑／赤で出ます。

GitHub Actions

push などをきっかけに、決めた手順（ここではテスト）を自動で実行する仕組み。

CI（継続的インテグレーション）

変更を取り込むたびに、自動でテストして問題がないか確かめ続けること。CI/CD の「CI」の部分。