tdd

tdd の概要

tdd は、red-green-refactor のループで機能追加やバグ修正を進めるための Test-Driven Development スキルです。実装ではなく振る舞いにテストを合わせたいエンジニアに向いています。リファクタリングが多いコードベース、インターフェースが重要な設計、そして壊れやすいテストに悩んでいるなら、この tdd スキルは、変更に耐えるテストを書く助けになります。

主な仕事はシンプルです。ざっくりした機能アイデアを、安全に小さく検証できる手順へ落とし込むこと。tdd スキルは、テスト自動化、統合寄りのテスト、そして境界が明確なコードに特に有効です。もっとも強い考え方は、公開インターフェース越しにテストし、本当にシステム境界と言える場所だけをモックすることです。

tdd は何のためのものか

新しい振る舞いの追加、バグ修正、あるいは安全網が必要なリファクタリングに対して、テスト先行のワークフローを取りたいときに tdd を使います。期待する結果は分かっているけれど、最もきれいな実装ルートはまだ見えていない、そんな場面に合っています。

この tdd スキルが違う理由

この repo は単に「先にテストを書こう」と言っているだけではありません。横断的に切り出すやり方を避け、振る舞い中心のテストを優先し、テストしやすいインターフェースを設計する、という具体的な規律を促します。そのため、速いけれど壊れやすいテストではなく、長く使えるテストが必要なときに、一般的なプロンプトよりも tdd スキルのほうが役立ちます。

tdd が向かないケース

単発の小さな unit test、使い捨てのスクリプト、あるいは内部呼び出しを大量のモックで確認したいだけなら、このツールはおそらく不向きです。このスキルは、将来リファクタリングする前提のソフトウェア向けであり、テストの数よりテストの質が重要なケースに向いています。

tdd スキルの使い方

スキルをインストールして読み込む

まずディレクトリの install コマンドで tdd install を実行し、そのあと最初に SKILL.md を開きます。続いて、出力品質を実際に左右するルールが書かれた tests.md、mocking.md、interface-design.md、refactoring.md、deep-modules.md を読みます。

解決策ではなく振る舞いを渡す

tdd usage で最も良い結果が出るのは、ユーザーに見える結果、入力、期待値がそろっているときです。強いプロンプトの形は次の通りです。

• 「checkout の検証を追加して、無効な cart は分かりやすいエラーを返し、有効な cart は支払いを完了するようにする」
• 「重複した email で 2 つの account が作られてしまう bug を修正する」
• 「public service interface を使って payment API に対する retry flow のテストを書く」

弱いプロンプトの形は次の通りです。

• 「checkout のテストを書いて」
• 「この module をもっと testable にして」
• 「database を mock して function が呼ばれたか確認して」

red-green-refactor のループに従う

まず、最小限で観測できる振る舞いから始め、その証拠になる failing test を 1 つ書き、通すために必要最小限の code を実装し、その後 test を green のまま保ちながら refactor します。テストを先に全部まとめて書いて、実装をあと回しにするのはやめてください。このスキルは horizontal slice を明確に避けるよう警告しています。なぜなら、それは検証された振る舞いではなく、想像上の振る舞いを増やしてしまうからです。

先に読むべきファイル

実務で進めるなら、優先順位は次の通りです。

• 哲学とワークフローは SKILL.md
• 良い test と悪い test のパターンは tests.md
• 境界だけを mock する考え方は mocking.md
• テストしやすい code にする設計は interface-design.md
• 最初の green のあとに改善すべき点は refactoring.md

tdd スキル FAQ

tdd は unit test 専用ですか？

いいえ。tdd スキルは、public interface を通した integration-style test を好むため、isolated な unit-heavy 構成よりも、test automation や behavior testing に向いていることが多いです。

すべてを mock する必要がありますか？

いいえ。tdd guide の基本ルールは、external API、time、randomness、場合によっては file system や database のような system boundary だけを mock することです。テストを通すためだけに自分の module を mock しないでください。

初心者でも tdd は使えますか？

はい。期待する振る舞いをはっきり説明できるなら使えます。主な学習ポイントは syntax ではなく、適切な boundary を選び、implementation-detail test を避けることです。

tdd は通常の prompt と何が違いますか？

通常の prompt は、コンパイルは通るがそれだけの test を出すことがあります。一方で tdd スキルはもっと意見がはっきりしており、behavior-first の test、小さな increment、そして refactor 中も test が安定する interface design を促します。

tdd スキルを改善するには

入力をもっと鋭くする

tdd では、振る舞い、境界、制約を含めるほど結果が良くなります。たとえば「テスト可能にして」ではなく、「実際の service wrapper を使う retryable な email sender を作り、time と external provider だけを mock して」と伝えます。

よくある失敗パターンに注意する

もっとも多い失敗は、over-mocking、private method のテスト、そしてユーザーが見るものではなく code の動き方を説明する test です。最初の案が implementation に寄りすぎていると感じたら、public API と observable result を明示して prompt を直してください。

test から design へ反復する

最初の出力のあと、失敗内容を使って interface design を改善します。parameters を小さくする、return value を分かりやすくする、副作用を減らす、といった改善です。もしまだテストしづらいなら、問題は test ではなく API の形にあるかもしれません。

green のあとに refactor の対象を指定する

振る舞いがカバーできたら、重複、長すぎる method、浅い module、feature envy、primitive obsession を洗い出すようにスキルへ依頼します。ここで tdd スキルの価値がさらに出ます。単に「通る test」を作るだけでなく、これからもテストしやすい、よりきれいな design へ進めるからです。