tdd-workflows-tdd-red

包括的な失敗するテストを、TDD のレッドフェーズの原則に従って作成します。

［拡張思考：test-automator エージェントを使用して、期待される動作を適切に定義する失敗するテストを生成します。］

このスキルを使用する場面

• 新しい動作の TDD レッドフェーズを始めるとき
• 期待される動作を捉えた失敗するテストが必要なとき
• 実装前にエッジケースを網羅したいとき

このスキルを使用しない場面

• グリーンフェーズまたはリファクタリングフェーズにいるとき
• パフォーマンスベンチマークだけが必要なとき
• 本番システムに対してテストを実行する必要があるとき

手順

1. 動作、制約、エッジケースを特定します。
2. 期待される結果を定義する失敗するテストを生成します。
3. セットアップエラーではなく、動作の欠如が原因で失敗することを確認します。
4. テストの実行方法と失敗の確認方法を記載します。

安全性

• テストデータを隔離し、本番環境を避けます。
• レッドフェーズでは不安定な外部依存関係を避けます。

役割

現在のプロジェクトのテストフレームワークと利用可能なツールを使用します。上流の Task／サブエージェントの種類はホスト固有であり、同梱されていません。また、委任が許可されるわけではありません。権限のある適合エージェントが存在しない場合は、テストを直接作成します。

プロンプトテンプレート

「次の内容について、包括的な失敗するテストを生成してください：$ARGUMENTS

主な要件

1. テスト構成

   • フレームワークに適したセットアップ（Jest／pytest／JUnit／Go／RSpec）
   • Arrange-Act-Assert パターン
   • should_X_when_Y 形式の命名規則
   • 相互依存のない隔離されたフィクスチャ

2. 動作の網羅

   • 正常系のシナリオ
   • エッジケース（空、null、境界値）
   • エラー処理と例外
   • 並行アクセス（該当する場合）

3. 失敗の検証

   • テストは実行時に必ず失敗すること
   • 正しい理由で失敗すること（構文／インポートエラーではない）
   • 意味のある診断エラーメッセージ
   • 連鎖的な失敗がないこと

4. テストカテゴリ

   • ユニット：コンポーネントの分離された動作
   • 統合：コンポーネント間の連携
   • コントラクト：API／インターフェースのコントラクト
   • プロパティ：数学的不変条件

フレームワークのパターン

JavaScript／TypeScript（Jest／Vitest）

• 依存関係を vi.fn() または jest.fn() でモックします
• React コンポーネントには @testing-library を使用します
• プロパティテストには fast-check を使用します

Python（pytest）

• 適切なスコープのフィクスチャを使用します
• 複数のテストケースにはパラメーター化を使用します
• プロパティベースのテストには Hypothesis を使用します

Go

• サブテストを使ったテーブル駆動テスト
• 並列実行には t.Parallel() を使用します
• より簡潔なアサーションには testify/assert を使用します

Ruby（RSpec）

• 遅延読み込みには let、即時読み込みには let! を使用します
• シナリオごとにコンテキストを使用します
• 共通の動作には共有例を使用します

品質チェックリスト

• 意図を明確に示す、読みやすいテスト名
• 1 つのテストにつき 1 つの動作
• 実装の詳細が漏れていないこと
• 意味のあるテストデータ（「foo」／「bar」ではない）
• テストが生きたドキュメントとして機能すること

避けるべきアンチパターン

• 最初からパスするテスト
• 動作ではなく実装をテストすること
• 複雑なセットアップコード
• 1 つのテストに複数の責務を持たせること
• 特定の詳細に依存する壊れやすいテスト

エッジケースのカテゴリ

• Null／空：undefined、null、空の文字列／配列／オブジェクト
• 境界値：最小値／最大値、単一要素、容量制限
• 特殊ケース：Unicode、空白、特殊文字
• 状態：無効な遷移、同時変更
• エラー：ネットワーク障害、タイムアウト、権限

出力要件

• インポートを含む完全なテストファイル
• テストの目的に関するドキュメント
• 失敗を実行・確認するコマンド
• 指標：テスト数、網羅する領域
• グリーンフェーズに向けた次のステップ」

検証

生成後：

1. テストを実行し、失敗することを確認します
2. 役立つ失敗メッセージであることを確認します
3. テストの独立性を確認します
4. 包括的に網羅されていることを確認します

例（最小）

// auth.service.test.ts
describe('AuthService', () => {
  let authService: AuthService;
  let mockUserRepo: jest.Mocked<UserRepository>;

  beforeEach(() => {
    mockUserRepo = { findByEmail: jest.fn() } as any;
    authService = new AuthService(mockUserRepo);
  });

  it('should_return_token_when_valid_credentials', async () => {
    const user = { id: '1', email: '[email protected]', passwordHash: 'hashed' };
    mockUserRepo.findByEmail.mockResolvedValue(user);

    const result = await authService.authenticate('[email protected]', 'pass');

    expect(result.success).toBe(true);
    expect(result.token).toBeDefined();
  });

  it('should_fail_when_user_not_found', async () => {
    mockUserRepo.findByEmail.mockResolvedValue(null);

    const result = await authService.authenticate('[email protected]', 'pass');

    expect(result.success).toBe(false);
    expect(result.error).toBe('INVALID_CREDENTIALS');
  });
});

テスト要件：$ARGUMENTS

制限事項

• このスキルは、タスクが上記のスコープに明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、成功基準が欠けている場合は、作業を中断して確認を求めてください。