TDDを整える。

＝テスト駆動開発のRed→Green→Refactorを、次へボタンで1周体験

失敗するテストを先に書く（Red）→そのテストを通す最小限の実装をする（Green）→テストが通ったままコードを整理する（Refactor）。この短いサイクルを「次へ」で1周たどりながら、各段階の「やること・やらないこと」を確認できます。テストファースト手順チェッカーは、実際にチェックした順番から「順序」の崩れを検出します。

💻 エンジニア

TLDR — 30秒で分かる

Red→Green→Refactorを円環図解＋「次へ」で1周体験。各段階のやること・やらないことを確認。テストファースト手順チェッカーは、チェックした順番から「実装を先にしてしまった」等の順序違反を検出。

主な機能

Red→Green→Refactorの円環SVG図解（次へ/戻る/最初からで1周を追体験）
各段階の「やること・やらないこと」を1行ずつ表示
テストファースト手順チェッカー：チェック順から順序違反を検出（決定論）
未チェック項目の抜けも同時表示
TDDとは（Kent Beckの一般的な要約）／BDDとの関係（通説）を解説
送信ゼロ・保存なし

⚠️ 「TDDとは」の説明は、Kent Beckが体系化したとされる考え方の一般的な要約です。特定の書籍・解説記事の言い回しをなぞったものではありません。

⚠️ Red/Green/Refactorの厳密な運用（1サイクルの粒度・テストの粒度など）は流派・現場により異なります。本ページの整理は一般的な一例であり、断定するものではありません。

DIAGRAM

Red → Green → Refactor サイクル図解

3つの状態がこの順で繰り返される円環です。「次へ」を押すと、1周を段階ごとに追体験できます。「戻る」で1つ前に戻れます。

—

下の「次へ」を押すと、Redから1周を追体験できます。

✅ やること

—

🚫 やらないこと

—

CHECKER

テストファースト手順チェッカー

実際にやった順にチェックしてください（上から順でなくてもOK）。チェックした「順番」を記録し、本来より後にやるべき手順を先にチェックしていないかを検出します。

実際の作業を、やった順にチェックチェックするそばから判定（送信ゼロ・保存なし）

1.失敗するテストを先に書いた
2.実行して、テストが失敗する（Red）ことを確認した
3.テストを通すための、最小限の実装をした
4.実行して、テストが成功する（Green）ことを確認した
5.重複や分かりにくいコードをリファクタリングした
6.リファクタ後も、すべてのテストがGreenのままであることを確認した

RESULT

チェックすると、ここに判定が出ます

① WHAT

TDDとは — 提唱者 Kent Beck

TDD（テスト駆動開発、Test-Driven Development）は、Kent Beckが体系化したとされる開発の進め方です。実装コードを書く前に、まずその機能が満たすべき条件を示す自動テストを書き、テストが失敗する状態（Red）から、テストを通す最小限の実装（Green）を経て、コードの内部構造を整理するリファクタリング（Refactor）へと進む、という短いサイクルを繰り返します。

重要なのは「自動テストを書くこと」自体ではなく、実装よりテストを先に書く、という順番にあるとされます。先にテストを書くと、そのテストは「これから作るものの仕様・使われ方」を先に決める役割を持ちます。逆に実装を先に書いてから後付けでテストを足すと、そのテストは「今書いたコードに合わせて通るように書かれたテスト」になりやすく、仕様を先に固定するという効果は得にくいとされます。上のチェッカーが「順番」を見ているのはこのためです。

② RELATION

BDDとの関係

TDDとBDD（振る舞い駆動開発、提唱者はDan Northとされます）は、しばしば対比して語られますが、対立する手法ではないとされます。TDDは主に開発者の視点で実装コードの正しさを内側から検証するのに対し、BDDはその外側で、ユーザーや業務の視点から「どう振る舞うべきか」を業務言語で記述し、関係者で合意することに重きを置く、という整理がされます。

現場によっては、BDDで合意した振る舞い（シナリオ）を出発点にしつつ、その内部実装をTDDのRed→Green→Refactorで進める、という併用のされ方もあります。どちらか一方を選ぶ・選ばないという関係ではなく、扱う抽象度（外側の振る舞いか、内側の実装か）が異なる、という捉え方が一般的です。詳しくは「BDDを整える」をご覧ください。

③ 使い方

「テストを書けばTDD」ではなく、先に書くリズムが本質。

1

まず円環図解で、1周の流れをつかむ。

「次へ」を押しながら、Red・Green・Refactorそれぞれの段階で「やること」だけでなく「やらないこと」も確認してください。特にRefactorで新機能を追加しない、という制約は見落とされやすいポイントです。
2

次に手順チェッカーで、自分の実際の作業順を検証する。

日々の開発の中で、6項目を実際にやった順にチェックしてみてください。「実装を先に書いてしまい、テストを後付けした」ような順序の崩れがあれば、⚠️としてその場で検出されます。
3

「テストを書けばTDD」ではないことを意識する。

自動テストが存在すること自体はTDDの証明にはならないとされます。実装より先にテストを書き、Red→Green→Refactorの短いリズムを繰り返すこと自体に価値がある、という一般的な整理を持ち帰ってください。

⚠️ 本ツールはTDDの一般的な整理の一例です。1サイクルの粒度・テストの書き方・チーム運用のルールは流派・現場により異なり、個別のプロジェクトのルールに優先するものではありません。

🧭 BDD・DDD・MSA・TDDは、同じプロダクトで同時に使われることが多い、選択問題ではない4つの技術です。設計の話をするときは、あわせてご覧ください。

BDDを整える → DDDを整える → MSAを整える → 開発プロセスを整える → 開発工程を整える →

🔒 サイクル図解・手順チェッカーの表示・判定はすべてこの端末（ブラウザ）の中で完結します。チェック内容はどこにも保存・送信されません（送信ゼロ）。

よくある質問

Q. TDD（テスト駆動開発）とは何ですか？

A. 実装コードを書く前にまず失敗するテスト（Red）を書き、それを通す最小限の実装（Green）をし、テストが通ったままコードを整理する（Refactor）というサイクルを繰り返す開発手法です。Kent Beckが体系化したとされます。「テストを書く」こと自体ではなく、実装より先にテストを書くリズムを繰り返す点が特徴とされます。

Q. テストを後から書くのと何が違うのですか？

A. 後から書くテストは「動くことの確認」が主な役割になりがちですが、先に書くテストは「これから作るものの仕様・使い方」を先に決める役割を持つとされます。本ツールの手順チェッカーで実際の作業順を記録すると、後付けのテストになっていないかを確認できます。

Q. リファクタリングの段階で新しい機能を追加してもいいですか？

A. 一般的には推奨されないとされます。Refactorはテストが通っている状態を保ったまま内部構造だけを整理する段階とされ、新しい振る舞いを追加するとその変更がテストで守られていない状態になるためです。新機能は次のRedから始めるサイクルで追加するのが一般的とされます。

Q. BDD（振る舞い駆動開発）とはどう違いますか？

A. TDDは実装コードを開発者視点で検証する手法、BDDはその外側でユーザーや業務の視点から「どう振る舞うべきか」を業務言語で記述し合意する手法、とされます。対立するものではなく、BDDで合意した振る舞いを内部ではTDDのサイクルで実装していく、という併用がされることもあります。

Q. 順番を守らないと何がまずいのですか？

A. 実装を先に書いてからテストを書くと、そのテストは「今書いたコードに合わせて通るように書かれたテスト」になりやすく、本来テストが持つ「仕様を先に固定する」役割が働きにくいとされます。手順チェッカーはチェックした順番を記録し、後の手順を先にチェックした箇所を検出して注意表示します。

入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。