keep-it-working

動作を維持する

目標はテストではありません。今日動くようになったものが、あと40回変更を加えた後も、何に触れてはいけないのかを知らないエージェントがいても、デモ当日に動くことです。

だから機能を追加するたびに考えるのは、「テストを書くべきか」ではありません。これが壊れたら気づけるか、気づかなかった場合にどれほどまずいかです。この2つに答えれば、どのレベルにするかは自ずと決まります。

段階

失敗を実際に検出できる、最も手軽な段階を選びます。リスクに見合わないほど上の段階に進むと、2週間のスプリントがテストプロジェクトになってしまいます。

段階	使う場面	やること
1. 見て確認する	レイアウト、文言、色、余白など、見ればすぐに失敗がわかる場合	ページを開いて、見る。それだけです。ここではテストを書いても割に合いません
2. 一連の流れをたどる	サインアップ → 作成 → 一覧で確認、のように、クリックして最後までたどれる複数ステップのフロー	実行中のアプリを最初から最後まで一度操作し、確認できたことを報告します。セットアップもファイルも不要です。playwright を参照してください
3. テストを1つ書く	壊れても気づきにくい場合や、手作業での確認に1分以上かかる場合 — バックグラウンドジョブ、Webhook、データベースへの往復処理など	正常系のテストを1つ書きます。テストスイートではありません。フロー全体の場合は playwright を使います
4. 先にテストを書く	コードが存在する前にルールを明確に述べられる場合、または再現できるバグを修正する場合	失敗するテストを書き、失敗することを確認してから、テストが通るようにします

テストファーストが本当に役立つとき

これは信条ではなく、計算です。次のような場合は、先にテストを書きます。

• 入力と出力を含む文でルールを説明できる。 「₹2000を超える注文は送料無料。ただし海外配送を除く。」料金、スコアリング、利用枠、上限、権限、日付計算などです。その文自体がテストになるため、先に書く手間はほとんどかからず、コードが勝手に逸れてしまう前にルールを明確にできます。
• バグを再現できる。 必ずそうします。引き起こせるバグなら1分でテストを書けます。また、それが修正の効果を確認し、その後も修正されたままであることを確かめる唯一の方法です。これは、スプリントプロジェクトにおいて最も価値の高いテストです。
• 分岐が多い。 空、1件、複数件、多すぎる、型が違う、有効期限切れ、使用済みなどです。クリックして5つのケースを確認するくらいなら、2回目以降はコードで確認するほうが速くなります。
• 何度も変更する予定がある。 すでに一度書き直したものは、また書き直すことになります。

次のような場合は、先にテストを書きません。

• 見た目に関すること。 テストには見えません。段階1または2を使います。
• まだ何が正しいのかわからない。 調査して動くようにしてから、テストを書く価値があるなら、テストで明確にします。先に調査するのは問題ありません。ただし、調査のままで終わりにしないでください。
• 一度きりのもの。 一度だけ実行するマイグレーション、偽データを投入するスクリプト、破棄することがすでに決まっているプロトタイプなどです。

譲れないルール

一度でも壊れたものには、必ずテストを付けます。 判断の余地も段階分けもありません。一度壊れたものは、また壊れる可能性があります。そして今なら、どうすればその状態を引き起こせるかが正確にわかっています。

これが、スプリントで最悪のパターンを防ぎます。火曜日に何かを直し、木曜日にエージェントが気づかないうちにまた壊し、デモまで誰も気づかない、というパターンです。

テスト環境は、必要になるまで構築しない

スプリント用スタックにはテストランナーが含まれていません。それで正しいのです。ほとんどの作業は段階1と2で済むからです。

変更が初めて本当に段階3または4に該当したとき、必要最小限のランナーをインストールし、そのテストを1つ書きます。設定ファイルでも、テストスイートでも、カバレッジでもありません。セットアップにスプリントの数分以上かかりそうなら、そのことを伝えて段階2を提案し、どちらにするかは相手に選んでもらいます。

テストが存在するようになったら

• 変更の内容に関係なく、変更のたびにテストを実行してください。
• テストスイートが失敗したら、そこで止めてください。新しいものを追加する前に修正してください。失敗したテストスイートの上に積み重ねると、午後があっという間に消えてしまいます。
• 自分が原因ではないものも含め、失敗はすべて名前を挙げて報告してください。赤いテストが何も言われないままスクロールして流れていくのは、言わないことで嘘をつくようなものです。
• テストに誠実さを保ちましょう。名前は動作を表し、アサーションはモックではなく実際の動作を対象にし、1つのテストでは1つの動作だけを検証します。失敗しないテストは、誤った安心感を与えるぶん、テストがないよりも悪いものです。

これについてどう話すか

「テストを書いておくべきでしたね」とは絶対に言わないでください。彼らは出荷する方法を学んでいる最中です。そして、罪悪感を抱えなくて済むように、この段階的な手順があります。

守る価値のあるものと、そのためにかかるコストを伝えてください。「料金ルールは気づかないうちに壊れやすいタイプです。2分でしっかりテストできますが、やってみますか？」と。それから、相手の答えを尊重してください。断られたら、それを記録して次に進みましょう。どちらの場合でも、checkpoint はそのまま利用できます。

テストがリグレッションを検出したら、そのことを声に出して伝えてください。その瞬間に、この考え方の価値が自ずと伝わります。

---

これは私たち独自のものです。レッド・グリーンの規律とテストの誠実さに関するルールは、obra/superpowers（MIT License）を参考にしています。段階的な手順と「いつ効果を発揮するか」という判断の仕組みは私たち独自のもので、スプリントで開発する人たちには、まず出荷し、その後に証明する必要があるからです。