正直に言うと、テストコードをちゃんと書いたことがありません（恥ずかしいですが本当です）。皆さんも共感されると思いますが、いつも実装ばかりに集中してしまい、テストは後回しにしがちでした。ただ、Djangoチームもそうですし、どこかで「テストコードの設計と作成にまず時間をかけるべきだ」と言われていたのを思い出して、今回Claude CodeのSkill機能を初めて使ってみるにあたり、TDD Skillを選んでみました。
Skillとは？
簡単に言うと、Claude Codeを使っていると、毎回同じ指示をプロンプトに入れなければならない場面がありますよね。Skillはそれをあらかじめファイルとして登録しておく機能です。呼び出すと、Claudeがその指示通りに動作する仕組みです。よく使う方法論やコーディング規約を一度まとめておけば、繰り返し再利用できるのでかなり便利です。
今回使ったSkill — obraのTDD Skill
GitHubスター112kのobra/superpowersリポジトリにあるスキルの中から、test-driven-developmentを選びました。なぜかって？スターが多いからです。
🔗 obra/superpowers - test-driven-development
TDDをご存知ない方のために
TDDとは、コードよりもテストを先に書く手法です。ログイン機能を例に説明しましょう。
従来の方法では、まずコードを書き始めて、エラーが出たら修正して、またテストして……を延々と繰り返しますよね。TDDは違います。コードを書く前に、まず**「合格基準」**を決めておくのです。
「ID: admin、パスワード: 1234でログインしたら成功するべき」
最初は機能がないので、当然テストは失敗します（🔴 Red）。そこで、このテストをギリギリ通過できる最小限のコードを書きます（🟢 Green）。グリーンになったら、その後のリファクタリングや新機能追加の際に、このグリーンが維持されているかを確認しながら修正を進めていく方式です（🔵 Refactor）。
先に方向性を定めてからコードを書くので、漠然と書き始めて迷子になるよりもずっと明確に進められます。
Skillファイルの中身を見てみる
MDファイルを開いてみると、目次がかなり充実していました。
- Overview
- When to Use
- The Iron Law
- Red-Green-Refactor
- Good Tests
- Why Order Matters
- Common Rationalizations
- Red Flags - Stop and Start Over
- Example: Bug Fix
- Verification Checklist
- When Stuck
- Debugging Integration
- Testing Anti-Patterns
- Final Rule
これを毎回TDDのたびにプロンプトに手入力しなければならないと想像すると、Skill機能のありがたさが実感できました。
構成を見ると、かなり体系的です。前半では**いつ（When to Use）、どうやって（The Iron Law）、何を（Red-Green-Refactor）、なぜ（Why Order Matters）**を押さえた上で、後半では実例とチェックリストで締めくくる流れになっています。
ところが中盤にCommon Rationalizations、Why Order Matters、When Stuckといったセクションが別途用意されているのが興味深かったです。これは何かというと、ClaudeがTDDを実行する際に自ら合理化したり、手順を飛ばそうとする状況をあらかじめ防ぐためのセクションです。
個人的に感じているのですが、Claudeはビッグテックの言語モデルの中でもかなり頑固な方です。業務に関係ないとか非生産的だと判断すると、どれだけ強く言っても聞いてくれません。つまり逆に言えば、「この方法がなぜ論理的で生産的なのか」を十分に納得させる必要があるということでもあります。Skillの作成者もそれを分かっていたのでしょう。人間が読んでも自然に理解できる順序と論理構造で組み立てられていたので、いずれ自分だけのSkillを作る際のリファレンスとして大いに参考になりそうです。
要点をまとめると
- 新機能、バグ修正、リファクタリング — 常にTDD
- 人間が「今回だけスキップして」と言ったらスキップする（ちゃんと言うことを聞くように）
- Iron Law: 必ずテスト失敗が先、その後にコードを書く — 「テストが全部通ったからバグはないはず」という落とし穴を防ぐための順序ルール
- Red-Green-Refactorの順序を厳守
- 🔴 Red: 失敗するテストをまず書く
- 🟢 Green: テストをかろうじて通過する最小限のコードを書く
- 🔵 Refactor: コードを整理する（重複排除、命名整理、不要なヘルパーの削除）
使ってみての感想
以上がざっくりとした要点で、かなり簡潔にまとめましたが、原文を実際に読んでみるとその論理構造が本当によくできています。私がわざわざ噛み砕いて説明する必要がないほどです。
実際に使ってみると、「テストから」というルールがあるおかげで実装の方向性が明確になりました。何を作るべきかをまず定義してから始めるので、コードが迷走することが減りました。そしてClaudeがこのSkillに従うとき、本当に忠実にRed → Green → Refactorの順序を守ってくれたのが印象的でした。
詳しい内容はぜひ原文を直接読んでみてください。読む楽しみを奪う必要はありませんから 😄