テストとは何か、なぜ必要なのか

Claude Codeがコードを変更し、"テストは通りました"と報告しました。この短い一言の裏には、検証用のファイル、実行コマンド、具体的な結果があります。まずテストの種類と手動で確認できることを見てから、自動テストとその結果の意味を説明します。

説明には、ポイントを付与する小さな例で十分です。テスト用ライブラリを前もって知っている必要はありません。最初にシナリオを手動で試し、次に自動テストへの期待を整理して、実行レポートを読みます。

テストの種類

テストを行うと、プログラムの動作や要件との一致、問題が起きる場所を確認できます。たとえば、ポイントが正しく加算されるか、空欄のまま申請を送れるか、エラーメッセージが分かりやすいかを調べます。そのために確認条件を決め、操作して、結果を見ます。

テストはさまざまな観点で分類できます。まず、誰が操作し、結果を確認するかを見てみましょう。

• 手動テスト - 人が自分で確認し、結果を評価します。
• 自動テスト - 検証の一部をプログラムに任せます。プログラムが指定された操作や比較を実行します。こうした個々の検証は、一般に自動テストと呼ばれます。

これは実行方法による分類です。もう1つの観点は、何を確認するかです。機能テストでは動作を確認します。たとえば、決められたポイントが付与されたかどうかです。非機能テストでは、アプリケーションの特性を調べます。応答速度や使いやすさなどが例です。この分類と実行方法は別々の観点なので、同じ機能を手動でも自動でもテストできます。

自動化しても人の役割はなくなりません。有用なシナリオを選び、期待する結果を決め、見つかった差異を調べる必要があります。繰り返しの作業をプログラムに任せられる、ということです。

手動テストとは

手動テストでは、自分で操作して結果が期待どおりか確認します。テストコードを書く必要はありません。必要なのは、分かりやすい条件と、答えを知りたい問いです。

学習用ポータルでは、一致1件につき10ポイントを付与するとします。3件なら30ポイントです。手動で確認する手順は次のとおりです。

1. 対象バージョンのポータルを開き、残高が0で、まだ報酬を受け取っていないユーザーを用意する。
2. 3件一致する申請を用意し、1回だけ送信する。
3. 送信後の残高を確認する。期待値は30ポイント。
4. 実際の結果を記録する。異なる値になった場合は、手順と必要に応じてスクリーンショットを保存する。

開始時の残高が大切です。すでに20ポイントあるなら、加算後の期待値は30ではなく50です。事前条件を決めておかないと、正しい結果を誤りと判断したり、その逆になったりします。

確認結果は簡潔に記録できます。"送信前の残高は0、3件一致、送信は1回、期待値は30、実際は3"。これなら、別の人やClaude Codeも再現すべき内容が分かります。"ポイントの動きがおかしい"だけでは伝わりません。

手動テストには探索的なやり方もあります。アプリケーションを調べながら、新しい確認項目を考えます。たとえば送信後もボタンが有効なことに気づき、もう一度押したらどうなるか試してみます。手順を最初から細かく決めておくわけではありませんが、動作を理解し、見つけた問題を記録する目的はあります。やみくもにクリックするのとは違います。

ツールを使ってもかまいません。ブラウザーのコンソールを開く、サーバーの応答を見る、スクリーンショットを撮る、確認項目を記録する、といった方法があります。"手動"とは、人がテストを進めて結果を評価するという意味で、ツールを使わないという意味ではありません。

新しい動作を調べたり、インターフェースが分かりやすいかを評価したりするなら、手動テストが便利です。一方、すでに決まっている操作や比較を繰り返すなら、自動テストが役立ちます。"画面の確認は手動、計算はコード"と決めつける必要はありません。ブラウザー操作も自動化できますし、計算を手動で確認することもできます。

自動テストの実行ボタンを押したあと、実際に確認するのはプログラムなので、それは手動テストではありません。一方、Claude Codeが手順の一覧を作り、それに沿って自分でポータルを操作して結果を評価したなら、テストは手動です。エージェントが準備を手伝っただけです。

自動テストとは

電卓を確認する場面を考えてみてください。2 + 2を入力し、答えは4だと分かったうえで、画面の数値と期待値を比べます。5と表示されたら、この例では結果が誤りだと分かります。電卓の表示にかかわらず、正解を知っているからです。

自動テストも同じような確認をプログラムで行います。初期条件を設定し、操作を実行して、結果を検証する小さなプログラムです。人の代わりにコードが比較します。ここからは、この自動テストを単にテストと呼びます。

報酬を付与するポータルに戻りましょう。一致1件につき10ポイント、3件なら30ポイントです。確認内容は次のように書けます。

1. 一致件数を3にする。
2. 報酬を計算する。
3. 報酬が30ポイントであることを確認する。

これで1つのテストになります。事前に分かっている例と期待値があります。"一致1件につき10ポイント"というルールは今回の学習用ポータルのものです。別のアプリケーションでは異なる場合があります。

テストがユーザーに何ポイント付与すべきかを自分で考えるわけではありません。要件からルールを取り出し、期待値として記録する人が必要です。開発者が決めることも、依頼を受けてClaude Codeが作ることもできますが、期待値がタスクの内容と合っているかは必ず確認してください。

テストを繰り返す理由

ポイントの加算を一度手動で確認するのは簡単です。問題はそのあとに起きます。新しい報酬を追加したり、申請処理を変更したり、エージェントに関数を簡潔にしてもらったりすると、そのたびに同じ疑問が出てきます。3件の一致で、今も30ポイントになるでしょうか。

毎回申請を用意して操作し、結果を確認することもできます。あるいは、確認内容をコードに記録して、何度でも実行できます。同じ条件を用意すれば、テストが操作と比較を繰り返します。どこを押すか、何を正解とするかを毎回説明する必要はありません。

プロジェクトが大きくなるにつれて、確認するルールも増えます。一致が0件ならポイントは加算されない。申請を繰り返しても報酬は二重に付与されない。報酬の一覧には決まった順序がある。複数のテストをまとめて実行すれば、変更によってどの期待値が満たされなくなったか分かります。

自動化の利点は、すでに記述した動作を再確認する手間が減ることです。テストを書くにも時間がかかり、要件が変われば見直しも必要です。それでも、何度も確認するルールなら、繰り返し実行することでその手間を補えます。

テストの保存場所

テストはプロジェクト内の通常のファイルに保存します。小さなJavaScriptプロジェクトなら、呼び出すコードの近くに検証用ファイルを置くと分かりやすくなります。

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

reward-flow.jsには報酬の計算があります。reward-flow.test.jsには計算を呼び出し、結果を確認するコードがあります。package.jsonにはプロジェクトの設定やコマンドが記されており、テストコマンドもその1つです。

ファイル名にある.test.jsを見ると、テスト用ファイルだと分かります。これはテストツールが対応している慣習で、JavaScript言語そのものの決まりではありません。別の名前を使うプロジェクトや、tests/という専用フォルダーを使うプロジェクトもあります。1つのファイルに複数のテストを書いてもかまいません。ソースファイルごとにテストファイルを用意する必要はありません。

Claude Codeが初めて扱うプロジェクトなら、既存のポイント加算テストを探してパスを示すよう、まず依頼してください。すべてのフォルダーを把握していなくても、確認内容と対象の動作を照らし合わせられます。

意図をテストにする

"ポイント加算を直して、テストで確認してください"という依頼では、エージェントに2つの疑問が残ります。正しい加算とは何か、結果を何で確認するのか、です。まず、期待する動作を説明しましょう。たとえば"一致1件につき10ポイントです。3件一致したら報酬は30ポイントです。"

この意図は、コードを1行も書かずにテスト内容へ整理できます。次の3点を決めてください。

1文にすると、"3件一致した場合、報酬の計算結果は30ポイントになる"です。テストの意味を話し合うには、これで十分です。このプロジェクトで検証コードをどう書くかは、エージェントが判断できます。

何を確認したいのかを選ぶことが大切です。"報酬が30と計算された"と"ユーザーの残高が30になった"は、別の期待値です。後者には開始時の残高と加算操作も必要で、先ほどの手動テストと同じです。"ポイントを確認して"という言い方は、具体的に観察できる結果に置き換えましょう。

次に、関連する状況も考えます。このルールなら、まず小さな表から始められます。

最初から何十通りものケースを考える必要はありません。問題が起きたシナリオと、変更の影響を受けそうな周辺ケースから始めましょう。たとえば申請を繰り返した場合の動作が分からなければ、まずルールを確認してください。エージェントは案を出せますが、それだけでは期待値に合意したことになりません。

Claude Codeにテストを依頼する

期待する動作が決まったら、それを軸に作業を進められます。まずエージェントが既存のテストを調べ、それを指定したシナリオと照らし合わせます。必要なテストがすでにあるなら、実行して結果を読むことが大切です。なければ、テストを追加してもらいます。

最初の依頼は、たとえば次のようになります。

報酬の計算を修正してください。
ルール: 一致1件につき10ポイントを付与します。
確認するケース: 3件一致なら30ポイント、
0件なら0ポイント、5件なら50ポイントです。

変更する前に、これらのケースを確認する既存テストを探してください。
すでに確認できていること、不足していること、
追加または変更を提案するテストを簡潔に説明してください。
要件に不明点があれば示してください。
まだファイルは変更しないでください。

回答は、これから得られる結果の説明として読んでください。数値はすべて自分のルールに基づいていますか。報酬の値そのものを確認していますか、それとも別のことですか。現在の動作に合わせるため、ルール自体を変える提案はありませんか。この段階ではテストの実装を読む必要はなく、タスクの内容を詰めていきます。

シナリオが固まったら、実作業を依頼します。

話し合ったルールに沿って計算を修正してください。
合意したケースで不足しているテストを、
プロジェクトで採用されているツールを使って追加してください。
テストを通すために既存の期待値を変更しないでください。
期待値が誤りだと思う場合は、理由を先に説明してください。

プロジェクトの手順に従って必要なテストを実行してください。
コマンド、作業ディレクトリ、実際の出力を示してください。
3つのケースそれぞれについて、確認したテストと
その結果を示してください。スキップされたテストと
実行されなかったテストは別に列挙してください。

実行コマンドは、エージェントがプロジェクトのドキュメントや設定から見つけます。JavaScriptプロジェクトではnpm testがよく使われます。npmはpackage.jsonのscripts.testフィールドに設定されたコマンドを実行します。この名前の下で動くテストはプロジェクトごとに異なります。必要なシナリオが実行に含まれているか確認してください。

テストを書いたことと、テストを実行したことは別です。"テストを3つ追加した"という報告から分かるのは、ファイルを変更したことだけです。結果を判断するには実際に実行する必要があります。依存関係がなくて実行できない場合などは、何が妨げになったのか、どのテストが未実行なのかをエージェントに示してもらいましょう。

回答では"自分のシナリオ → 該当するテスト → 結果"のつながりを確認してください。話し合った3ケースのうち1つしか実行されていなければ、確認できたのはその1つだけです。最後の行が緑色でも変わりません。

実行結果の読み方

以下はNode.js 20.18.0とnpm 10.8.2で、学習用テストを1つ実行した実際の例です。確認するのは3件一致した場合の報酬計算だけで、先ほど挙げたすべてのシナリオではありません。読みやすくするため、時間表示とレポートの補助情報は省いています。

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

最初の2行にはパッケージと実行したコマンドが表示されています。その下がテスト名です。ok 1はテスト番号1が成功したことを示します。失敗した場合はnot okで始まります。pass 1とfail 0から、1件が成功し、失敗はなかったと分かります。ターミナル上で色が付いていなくても、これが"緑"の結果です。

誤りがある場合、3件一致で報酬が3ポイントになり、ルール上の30ポイントと食い違います。同じテストを実行すると、次のような箇所が表示されます。パス、スタックトレース、時間、一部の補助情報は省略しています。

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

まずテスト名を見てから、expectedとactualを比べてください。前者は"期待値"、後者は"実際の値"です。ここでは期待値が30、実際の値は3です。fail 1の行は、テストが1件失敗したことを示しています。

この失敗は、実際の値が記録された期待値と一致しなかったという意味です。原因を調べましょう。計算の誤りか、初期データの誤りか、テスト自体の期待値が間違っているのかもしれません。レポートを成功させるためだけに検証値を変えてはいけません。まずタスクのルールを確認してください。

別の種類の失敗もあります。たとえばテストが関数のファイルを読み込めない場合、ポイントを比較するところまで進みません。レポートに対象テストの名前がなく、ファイル全体が失敗として表示されることもあります。そのため、fail 1だけでは"計算が誤っている"とは判断できません。集計の前に表示されたメッセージも確認してください。

スキップされたテスト

テストにはもう1つ大切な状態があります。確認項目をスキップ扱いにできます。Node.jsでは、たとえばtest.skipを使います。このテストは実行されません。レポートに名前があるからといって、そのシナリオを確認したことにはなりません。

同じ例でテストをスキップして実行すると、次の行と集計が表示されます。

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

少し紛らわしい点に注目してください。行はokで始まりますが、末尾には# SKIPがあります。この形式では、こうしてスキップを示します。最初の単語だけを見てはいけません。pass 0の集計から、成功したテストがないと分かります。

同じシナリオを実行した3つの結果をまとめます。

大きなレポートにはほかの行もあります。今回の例ではcancelledとtodoは0です。0以外なら、キャンセルされたテストや未完了として記録されたテストを調べ、確認済みに含めないでください。suitesはテストのグループを示します。この例にはグループがありません。

もう1つ、小さな注意点です。レポートにテストが0件と表示されていたら、失敗がないからといって加算を確認できたわけではありません。必要なテストが実行対象に入っていない可能性があります。ターミナルの色より、シナリオ名と実行されたテストの数を見てください。

緑の結果が意味すること

このレポートのテストが答えたのは、"3件一致したとき、報酬は正しく計算されたか"という限定的な問いです。一致が0件の場合や申請の再送、画面上の数値は確認していません。依頼文で触れたからといって、それらのケースまでテスト済みにはなりません。

一致が0件の場合を確認するなら、期待値を0とする別のシナリオが必要です。申請の再送を確認する場合は、再度操作したときの期待値を具体的に説明します。テストは周辺のコードからルールを推測しません。記録されている内容だけを確認します。

テストがないことと、テストがスキップされたことは別です。スキップされたテストはskippedとしてレポートに表示されます。一方、確認用テストをまったく書いていないシナリオについては、通常レポートに何も表示されません。未確認の動作に誤りがあっても、既存のテストがすべて通ることはあります。

最後に、比較が成功しても期待値そのものが正しいとは限りません。ルールに反して30ではなく3を期待値に設定し、計算結果も3なら、比較は成功します。テストを検討するときは、何の動作を確認しているのか、期待値の根拠は何か、の2点を確かめてください。

"テストは通りました"という報告は、その範囲を理解していれば役立ちます。特定の実行で、特定のテストが成功したことを伝えるものです。"アプリケーションにもうバグはない"という保証ではありません。