test-driven-development

機能を作るとき、不具合を直すとき。実装のコードを書く前です。

やることは 3 行

やることは 3 行で書かれています。

テストを先に書く。落ちるのを見る。通る最小のコードを書く。

中核の原則が、なぜ「見る」必要があるかを言っています。

テストが落ちるのを見ていないなら、それが正しいものをテストしているか分からない。

これが正確です。テストを書いて最初から通ってしまった場合、そのテストはすでにある振る舞いを見ているだけです。

鉄の法則と、先に書いたコードの扱い

失敗するテストが無いところに、本番のコードは無い

そのうえで踏み込んだ指示が続きます。

テストより先にコードを書いた？消せ。やり直せ。

例外は無い。「参考」として残すな。テストを書きながら「合わせる」な。見るな。消すというのは消すという意味である。

テストから新しく実装する。以上。

「見るな」まで書いてあるのが特徴です。残したコードを見ながらテストを書くと、テストがそのコードの形に寄ります。

使う場面と、例外

そして 1 行。「『今回だけ TDD を飛ばそう』と考えている？止まれ。それは合理化である。」

赤→緑→整えるの各段に「確認」が挟まる

本文には流れ図まで入っていますが、要点は各段のあとに検証があることです。

1. 赤何が起きるべきかを示す最小のテストを 1 つ。そのあと 落ちるのを見る（必須）
2. 緑通す最小のコード。そのあと 通るのを見る（必須）
3. 整える綺麗にする。そのあと緑のままか確認

赤の確認で見るものが 3 つ

• テストが落ちる（エラーで終わるのではない）
• 失敗の文言が期待どおり
• 機能が無いから落ちている（打ち間違いではない）

そして分岐まで決まっています。

「落ちた」と「エラーになった」を分けているのが丁寧です。

緑の確認は「プロジェクト全体の試験」

緑の段には、自分が書いた試験だけが通っても全体が通ったことにはならない、という決まりがあります（2026 年 9 月の改訂から）。

タスクが 1 つの試験のファイルしか指定していなくても、完了と言う前にプロジェクトの試験のコマンド（pytest、npm test、cargo test など）を流せ、と書かれています。

自分のせいでない失敗も、名前を挙げて報告に入れる決まりです。見て見ぬふりをした赤い試験は、「書かなかったことで偽った報告」だとしています。

良いテストと悪いテストを並べて見せる

本文には対になったコード例が入っています。

悪い例への評が 1 行です。「曖昧な名前、コードではなくモックをテストしている。」

先回りの機能は YAGNI

緑の側にも対の例があります。悪い例は、テストが要求していないオプション（再試行の上限、待ち方、コールバック）を先に用意したもので、YAGNI と評されています。

テストが要求する以上に、機能を足すな、他のコードを書き直すな、「改善」するな。

要件が 3 つだけ

赤の段のテストに求められるもの。

• 1 つの振る舞い
• 明確な名前
• 実際のコード（避けられない場合を除いてモックを使わない）

テストを書く・変えるときは同梱の資料を読む

同梱の writing-good-tests.md は、テストを書くとき・変えるときに読め、と本文が指している資料です。「どの本番の変更でこのテストが落ちるかを先に言う」「実物を動かす」の 2 原則が柱です。

本文はそこから 4 つを抜き出しています。モックではなく実際の振る舞いを確かめる、テスト専用のコードを本番のクラスに置かない、依存をモックにする前にその副作用を理解する、が残りの 3 つです。

捨てる試作

捨てる試作には向きません。本文が例外に挙げていますが、人に聞けという条件が付いています。

見た目の良し悪し

見た目の良し悪しは測れません。自動テストで判断できない対象です。

探索の段階

探索の段階では重いです。何を作るか決まっていないうちにテストから入ると、テストの作り直しが増えます。

既存の変更を消されたくないとき

強い方針があります。テストより先に書いたコードを消させる指示が入っています。既存の変更を無条件に消されたくない場合は、作業の範囲を先に区切ってください。

テストする境界から決めたいとき

テストする境界から決めたいなら別物です。tdd は合意していない境界ではテストを 1 件も書きません。違いは後述します。

解析では拾えないが、テストを書いて走らせる

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 1 件です（2026-10-09 確認）。

ただし実際にはテストと実装を書き、テストを走らせます。解析が拾っていないのは、それらが地の文とコード例で書かれているためです（スキルを入れる前に確認すること）。

先に書いたコードを消す指示がある

テストが DB や外部 API を書き換えることがある

テストが DB や外部 API を書き換える場合があります。隔離された検証環境を用意してください。外部サービスを使うテストは、繰り返し実行すると費用がかかります。

モックを避ける方針

モックを避ける方針です。実際のコードをテストする指定なので、外部への接続が必要なテストが増える可能性があります。

テストの実行回数が増える

赤と緑の確認が必須なので、テストの実行回数が増えます。遅いテストのプロジェクトでは待ち時間が積み上がります。

ライセンス

ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。

なぜ落ちるのを見る必要がありますか

正しいものをテストしているか分からないからです。

テストを書いて最初から通った場合、それはすでにある振る舞いを見ているだけです。本文もその場合は「テストを直せ」と指示しています。

すでに書いたコードは残せませんか

残せません。「参考として残すな」「合わせるな」「見るな」「消すというのは消すという意味」と 4 重に書かれています。

残したものを見ながらテストを書くと、テストがそのコードの形に寄ります。

「落ちた」と「エラーになった」は違いますか

違います。落ちるのは期待どおり、エラーで終わるのは打ち間違いなどが原因です。

本文は「エラーを直して、正しく落ちるまで走らせ直せ」と指示しています。

モックは使えませんか

避けられない場合だけです。要件に「実際のコード（避けられない場合を除いてモックを使わない）」とあります。

悪い例として「コードではなくモックをテストしている」が挙げられています。

mattpocock の tdd とどちらを使いますか

扱っている層が違います。

手順の型が欲しいならこちら、テストの質で困っているならあちらです。両方入れると赤 → 緑の指示が二重になります。

対応しているエージェントはどれですか

Claude Code と Codex です。公開元は群の入口（using-superpowers）に実行環境ごとの補足ファイルを置き、writing-skills では Claude Code・Codex・Copilot CLI・Gemini CLI の置き場所まで書き分けています。

当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。