mcpField
T
tdd

tdd

github.com/jellydnテスト・品質12646 回インストール4 日前に更新
リポジトリ

tdd について

テストコマンドの確認から Red-Green-Refactor サイクルまで、テスト駆動開発を案内するスキルです。振る舞いを検証するテスト、小さな垂直スライス、失敗理由の確認を重視します。

主な機能

  1. 01Red-Green-Refactor ワークフロー
  2. 02テストランナーの確認
  3. 03振る舞いを検証するテスト
  4. 04継続的なテストフィードバック
  5. 05テスト状況と次の手順の確認

活用シーン

  1. 01機能開発での TDD 開始
  2. 02期待する振る舞いのテスト作成
  3. 03テストを通す最小限の実装
  4. 04テストを維持したリファクタリング

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jellydn/my-ai-tools --skill tdd

インストール後、Claude Code で/tddを入力して読み込まれたか確認します。

同梱ファイルtemplates/test-template.md

詳細

テスト駆動開発(TDD)

Red-Green-Refactor サイクルによる、TDD ワークフロー全体をガイドします。

使い方

/tdd <ACTION> [ARGUMENTS]

アクション

  • start - 機能の TDD セッションを開始します
  • red <TEST_NAME> - 失敗するテストを作成します(Red フェーズ)
  • green - テストを実行してコードを実装します(Green フェーズ)
  • refactor - リファクタリングのプロセスをガイドします(Refactor フェーズ)
  • cycle - Red-Green-Refactor サイクル全体を実行します
  • watch - 継続的にフィードバックを得るため、テストウォッチャーを開始します
  • status - 現在のテスト状況と次の手順を表示します

TDD の原則

Red-Green-Refactor サイクル
  1. Red:望ましい振る舞いを定義する、失敗するテストを書きます
  2. Green:テストに合格するための最小限のコードを書きます
  3. Refactor:テストを成功状態に保ちながら、コードの品質を向上させます
ベストプラクティス
  • まずテストを書く - テストでインターフェースと振る舞いを定義します
  • 小さなステップ - 少しずつ段階的に変更します
  • 素早いフィードバック - すぐに検証できるよう、頻繁にテストを実行します
  • クリーンなコード - 品質を保つため、定期的にリファクタリングします
  • 1 つのテストにつき 1 つの概念 - テストの対象を絞り、単一の目的にします
  • AAA パターン - Arrange、Act、Assert の構成でテストを記述します
  • ブラックボックステスト - 実装の詳細ではなく、パブリックメソッドと振る舞いのみをテストします
  • 合意済みの境界でテストする - テストを書く前に、振る舞いを公開するパブリックインターフェースを特定し、既存の最も高い境界を優先します
  • 期待値は独立させる - 期待値はリテラル、具体例、または仕様から得ます。実装と同じアルゴリズムで再計算してはいけません
  • 垂直スライス - 意味のあるテストを 1 つ書き、最小限の実装を行い、その後繰り返します。最初のサイクルから学ぶ前に、想定したテストスイート全体を書こうとしてはいけません
アンチパターン
  • 実装に結合したテストは、プライベートな依存先をモックしたり、内部状態を調べたりします。無害なリファクタリングでも失敗し、振る舞いに対する信頼性も低くなります。
  • トートロジー的なテストは、テスト対象のコードと同じロジックで期待値を導き出すため、両方が同時に間違っている可能性があります。
  • 水平スライスでは、すべてのテストを先に書き、実装は後でまとめて行います。一度に 1 つのユーザーに見える振る舞いを検証する、トレーサーバレット型のスライスを優先してください。
  • 未確認の境界では、到達しやすいというだけの理由で低レベルのヘルパーをテストします。より高いインターフェースで重要な振る舞いをテストできる場合は、そちらでテストするか、低い境界が適切な理由を記録してください。

最初の Red フェーズの前に、マニフェスト、タスクランナー、ドキュメント、または CI から、リポジトリのテストランナーとコマンドを特定してください。TypeScript、Vitest、npm、pnpm を前提にしてはいけません。Red の失敗時に使用した正確なコマンドと、失敗した理由を記録してください。構文エラーやインポートエラーは、正当な Red 状態ではありません。

プロセス

「start 」の場合:
  1. 機能の TDD セッションを開始します
  2. 対象のソースファイルを作成するか、特定します
  3. 対応するテストファイルがなければ作成します
  4. 機能要件と受け入れ基準を説明します
「red <TEST_NAME>」の場合:
  1. 望ましい振る舞いを説明する、失敗するテストを作成します
  2. 正しい理由で失敗することを確認します(構文エラーではないこと)
  3. テストを実行し、Red 状態を確認します
  4. テストで検証している内容を説明します
「green」の場合:
  1. 失敗するテストに合格するための最小限のコードを実装します
  2. 完璧なコードではなく、テストに合格させることに集中します
  3. テストを実行し、Green 状態を確認します
  4. テストに合格するために必要な分だけコードを書きます
「refactor」の場合:
  1. テストを成功状態に保ちながら、コードの品質を向上させます
  2. 重複をなくし、設計を改善します
  3. リファクタリング中は継続してテストを実行します
  4. 一度に 1 つの変更をリファクタリングします

テストテンプレート

テストテンプレートは $SKILL_PATH/templates/test-template.md にあります:

import { describe, it, expect } from "vitest";
import { functionName } from "./module";

describe("functionName", () => {
	it("should return formatted output when given valid input", () => {
		// Arrange - Setup test scenario
		const input = "test input";
		const expectedOutput = "expected output";

		// Act - Execute the unit under test
		const result = functionName(input);

		// Assert - Verify expected outcome
		expect(result).toBe(expectedOutput);
	});
});

よく使うコマンド

  • テストを実行:npm test または pnpm test
  • ウォッチモード:npm test --watch
  • カバレッジ付き:npm test --coverage

コメント