テストという考え方(壊れを自動で見張る)

この章でわかること: 手で触って確かめる確認とは別に、「壊れていないか」を機械に 自動で見張らせるという考え方。テスト自体はAIに書かせて実行させられます。仕組みの 名前を覚える必要はなく、発想さえ持てば十分です。

なぜテストが要るのか

プロトタイプは、一度作って終わりではありません。「ここも直したい」「あの機能も」と、 何度も手を入れていきます。問題は、手を入れるたびに、前まで動いていた所が こっそり壊れることがある点です。

かといって、変更のたびに全画面・全操作を手で試し直すのは現実的ではありません。 機能が5個あれば5通り、10個あれば10通り。数が増えるほど、確認は時間を食い、 そして必ずどこかを見落とします。「たぶん大丈夫」で先に進んだ結果、商談当日に 別の場所が動かない——これが一番避けたい事故です。

そこで登場するのがテストです。

テストとは「こう動くはず」を先に書いておくこと

テストとは、ひとことで言えば 「この操作をしたら、こうなるはず」を一つずつ 書き留めた確認リストです。しかも、そのリストを機械が自動で実行してくれます。

たとえば問い合わせフォームなら、こんな具合です。

• 名前とメールを入れて送信 → 「完了しました」と出るはず
• 空欄のまま送信 → 「入力してください」とエラーが出るはず
• メール欄に変な文字 → はじかれるはず

これを一度書いておくと、以後はボタン一つで全部を一気にチェックできます。 人間が毎回手で試す代わりに、機械が黙々と「はず」の通りかを見てくれる——これが テストの正体です。健康診断の項目表を一度作っておけば、毎年同じ項目を機械的に 測り直せる、あのイメージに近いものです。

手で触る確認との違い

生成物の良し悪しの見分け方で扱った「自分が利用者に なって触る」は、その場・その一回の確認です。テストは、その確認を文章にして 保存し、以後は毎回・自動で回すもの。両方は対立せず、役割が違います。手で触って 「この動きは大事」と気づいた所を、テストとして残していくのが自然な流れです。

テストはAIに書かせて、実行させる

「テストを書く」と聞くと身構えますが、書くのも実行するのもAIに任せられます。 あなたがやることは、「何が正しい動きか」を言葉で伝えることだけです。正しさを 知っているのは、コードを書く人ではなく、仕事や顧客を分かっているあなたの方です。

AIにこう頼むと良い

「この問い合わせフォームに、動作を確認するテストを書いて。 (1) 正しく入力して送信すると完了メッセージが出る、 (2) 空欄で送信するとエラーが出る、 (3) スマホ幅でも主要な操作ができる——この3つを確認したい。 書いたら実際に実行して、結果も教えて」

正しく動く物には、テストは**全部「合格(緑)」**と表示されます。どこかが 「はず」の通りでなければ、どの項目が・どう食い違ったかを機械が教えてくれます。 結果の見方が分からなければ、それも「この結果を専門用語なしで説明して」と AIに聞けば十分です。

変更のたびに走らせる(回帰をとらえる)

テストの本当のありがたみは、作った後に出ます。何か直したら、そのつど テストを走らせる。ここまで動いていた機能が巻き添えで壊れていれば、機械が 即座に「ここが赤い」と教えてくれます。

前は動いていた所が、あとの変更で壊れてしまうことを**回帰(リグレッション)**と 呼びます。人間が気づきにくいのは、まさにこの「関係ないと思っていた場所」の 巻き添えです。テストは、そこを毎回・機械的に見張ってくれます。

これは一度に一つだけ変えるの型と、きれいにかみ合います。 小さく変える → テストを走らせる → 全部緑ならコミット → 次へ。この一往復に テストを一行加えるだけで、「壊れたのに気づかないまま進む」事故がほぼ消えます。

AIにこう頼むと良い

「今の変更を加えたあと、前からあるテストも全部実行して、緑のままか確認して。 もし赤くなった項目があれば、原因の見立てと直し方をあわせて教えて」

プロトタイプでは、どこまでやるか

ここが肝心です。プロトタイプに、あらゆるテストは要りません。全機能・全パターンを 網羅しようとすると、テスト作りだけで時間が溶け、本末転倒です。

判断の目安はシンプルです。「デモで必ず見せる操作」と「壊れると恥をかく所」だけ テストしておけば十分です。

• 顧客の前で必ず通す主要な操作(入力 → 送信 → 完了、など一本の流れ)
• 壊れると印象が最悪になる所(お金の計算、日付、件数の集計など)
• 過去に一度壊れた所(同じ所は再発しやすい。ここは残す価値が高い)

逆に、まだ変わりそうな画面の細部や、見た目の微調整にテストを厚く盛るのは やりすぎです。プロトタイプは変化が前提。変わりにくい芯にだけ、見張りを 置いておく——それがちょうどよい塩梅です。

テストは万能ではない

テストが全部緑でも、それは**「書いた項目については正しい」という意味でしかありません。 書き忘れた観点は見張れません。だからテストと、手で触る確認は 両輪です。特に見た目の崩れやスマホでの使い心地**は、最後は自分の目で 確かめましょう。

なぜ大事か

コードが読めないと、「今の変更で、どこかを壊していないか」が一番の不安になります。 テストは、その不安を機械に肩代わりさせる仕組みです。あなたは「何が正しいか」を 言葉にするだけでよく、見張りは機械がやってくれる。

商談でプロトタイプを見せるなら、その場で確実に動くことがすべてです。主要な 操作にテストを置き、変更のたびに走らせておけば、直前の手直しで壊しても即座に 気づけます。「動いているはず」で祈りながらデモに臨む状態から、「機械が緑を 出している」という根拠を持ってデモに臨む状態へ。この差は、当日の落ち着きに そのまま表れます。

参考リンク(情報ソース)

• 自動テストの導入 — MDN — 手で試す代わりに機械に確認させる、という発想の一次情報(MDN Web Docs)
• Vitest — Getting Started(公式) — 近年よく使われるテストツールの公式ドキュメント(英語)
• Jest 公式ドキュメント(日本語) — 代表的なテストツールの一次情報