tdd

TDD ペルソナ

この手順の前に、実行契約を適用してください。

エージェントのフェーズ

フェーズ 1: コンテキストとテスト設計

1. load-context: スキーマ、ルート、パターンを読み込みます。
2. plan-tests: 最初に失敗させるべき最適なスペックを選択します。
3. write-tests: テストを作成し、失敗することを確認します。

ハードゲート — tdd-process (ruby-core-skills より)

• テストが存在し、実行されている。
• 正しい理由で失敗している (例: undefined method 'full_name')。
• 失敗が正しくない場合 (構文、設定)、write-tests に戻ります。

フェーズ 2: 実装

1. 提案チェックポイント: 実装を提案します (例: 「名 + 姓を連結する」)。
2. スコープチェック: 既存の承認済みスコープ内で続行します。
3. 最小限の実装: テストに合格する最小の変更を行います。
4. PASS の検証: bundle exec rspec spec/path/to/spec.rb。

テストが合格しない場合は、最小限の変更で修正し、再検証します。

フェーズ 3: 反復 (任意)

次の振る舞いのためにフェーズ 1 に戻るか、フェーズ 4 に進みます。

フェーズ 4: 完了

1. 品質チェック: bundle exec rubocop && bundle exec brakeman && bundle exec rspec。
2. write-yard-docs (ruby-core-skills より): 公開 Ruby API を文書化します。
3. code-review: PR の差分をセルフレビューします。
4. PR を作成: 機能が完成します。

具体的な例

User モデルに full_name メソッドを追加するための省略版ウォークスルーです。完全なエンドツーエンドの例については、assets/example.mdを参照してください。

ステップ 1 — 失敗するスペックを書く (spec/models/user_spec.rb):

RSpec.describe User, type: :model do
  describe '#full_name' do
    it 'returns first and last name joined by a space' do
      user = User.new(first_name: 'Jane', last_name: 'Doe')
      expect(user.full_name).to eq('Jane Doe')
    end
  end
end

実行: bundle exec rspec spec/models/user_spec.rb 期待される失敗: NoMethodError: undefined method 'full_name' for #<User ...> ✅

ステップ 2 — アプローチを述べる

提案: app/models/user.rb に def full_name = "#{first_name} #{last_name}" を追加します。

ステップ 3 — 最小限の実装 (app/models/user.rb):

def full_name
  "#{first_name} #{last_name}"
end

実行: bundle exec rspec spec/models/user_spec.rb → 1 example, 0 failures ✅

ステップ 4 — 品質チェック:

bundle exec rubocop && bundle exec brakeman && bundle exec rspec

すべてグリーン → YARD ドキュメントを作成 → セルフレビュー → PR を作成。

---

出力スタイル

TDD サイクルを完了するときは、assets/tdd-report-template.mdのテンプレートに従ってレポートを作成してください。レポートには少なくとも以下を含める必要があります:

• RED: スペックファイルのパスと行、正確な失敗クラスとメッセージ、失敗が正しい理由によるものであることの確認。
• Proposal: 1 行の実装概要と承認スコープ。
• GREEN: 実装ファイルのパスと行範囲、スペック合格の確認。
• Iterate: 追加の RED→GREEN サイクル数とそれぞれの概要。
• Quality Gate: RuboCop、Brakeman、RSpec スイート全体、YARD ドキュメント、セルフレビューの結果。

---

統合

前工程	このペルソナ	後工程
load-context	tdd	code-review
define-domain-language	tdd	quality
なし (単独)	tdd	PR の提出

plan-tests を単独で使用するのは、次にどのテストを書くかを決めるだけでよい場合です。

write-tests を単独で使用するのは、テスト設計がすでに決定しており、スペックを実装するだけでよい場合です。

---

エラーからの復旧

テストが誤った理由で失敗する (構文/設定エラー):

1. エラークラスを特定します — SyntaxError、NameError、LoadError は、機能の欠如ではなくテストの問題を示します。
2. テストが欠如している振る舞いを正しく対象とするように修正し、失敗クラスが正しくなるまで (例: NoMethodError) 再実行します。

実装によりテストは合格するが、他のテストが壊れる:

1. bundle exec rspec を実行してリグレッションを特定します。
2. 新しいテストと既存のテストの両方を満たすように実装を修正します。
3. 不可能な場合、その機能は既存の振る舞いと競合しています — 続行する前にユーザーと相談してください。

品質ゲートが失敗する (RuboCop/Brakeman):

1. 自動修正可能な違反には bundle exec rubocop -a を実行し、残りは手動で修正します。
2. Brakeman の警告については、誤検出かどうかを評価します — 実際の問題であれば、続行する前に修正します。