test-driven-development

name	test-driven-development
description	TDD（テスト駆動開発）スキル。dotfilesのコード変更時にRed-Green-Refactorで進め、対象OSに応じてmacOS/Ubuntu/Windowsの参照ガイドを読み分ける。Use when: 開発、実装、コード変更、テスト追加・修正を依頼された時。

テスト駆動開発（TDD）

この Skill は、dotfiles リポジトリでコード変更を行うときの共通入口です。

TDD の進め方は共通ですが、実装・検証に使う技術スタックは OS ごとに異なります。作業対象の OS を判断し、必要な reference だけを読んでください。1つの OS の作業で、他 OS の詳細を読む必要はありません。

OS別ガイドの選択

変更ファイル、依頼内容、setup の呼び出し先から対象 OS を判断します。

対象	読む reference
macOS / Homebrew / Bash / BATS	references/macos.md
Ubuntu / Linux / Bash / BATS	references/ubuntu.md
Windows / PowerShell / winget / Pester	references/windows.md

複数 OS にまたがる変更では、対象 OS の reference をそれぞれ読みます。対象 OS が不明な場合は、まず変更対象ファイルのパスと既存テストから判断します。

TDDサイクル

フェーズ	目的
Red	期待する振る舞いをテストにし、失敗を確認する
Green	テストを通す最小限の実装を行う
Refactor	テストを通したまま、重複や読みづらさを整理する

共通原則

1. 実装前に、できるだけ先にテストを書く。
2. 既存の OS 別ディレクトリ構造とテスト配置に合わせる。
3. 変更範囲を狭く保ち、関係のない OS へ知識や依存を漏らさない。
4. 実システムを変更する処理は、dry-run やモックしやすい設計を優先する。
5. Red / Green / Refactor の各段階で、実行したコマンドと結果を簡潔に把握する。

進め方

1. Red

• 要件から期待する振る舞いを1つ以上のテストにする。
• 対象 OS の reference に従って、BATS または Pester のテストを追加・修正する。
• テストを実行し、意図した理由で失敗することを確認する。

2. Green

• テストを通す最小限の実装を行う。
• 既存スクリプトの責務分離、命名、エラーハンドリングに合わせる。
• 追加・修正したテストを再実行し、成功を確認する。

3. Refactor

• 重複、曖昧なメッセージ、テストしづらい分岐を整理する。
• 対象 OS の lint / format / 追加検証を実行する。
• 複数 OS にまたがる変更では、影響範囲ごとに必要な検証を行う。

ドキュメントのみの変更

ドキュメント変更では、必ずしも Red-Green-Refactor を厳密に適用しません。

ただし、コマンド例、ファイルパス、Skill の参照先を変更した場合は、実在するパス・コマンド名と矛盾しないか確認します。

完了時の報告

最終報告では、次を簡潔に含めます。

• 変更内容
• 対象 OS
• 実行したテスト・検証
• 未実行の検証がある場合、その理由