test-driven-development

テスト駆動開発（TDD）

Red-Green-Refactorサイクルに基づくテスト駆動開発を支援します。

TDDサイクル

TDD原則

1. テストファースト: 実装前に必ずテストを書く
2. 最小実装: テストを通す最小限のコードのみを書く
3. リファクタリング: グリーンになった後、コード品質を改善
4. 小さなステップ: 一度に1つの機能に集中
5. 継続的な実行: テストを頻繁に実行し、即座にフィードバック

開発手順

1. Red（失敗するテストを書く）

• 要件を理解し、期待する振る舞いを定義

• テストケースを作成（エッジケース、境界値も考慮）

• テストを実行して失敗を確認

  # プロジェクト固有のテストコマンドを実行
  
  # Shell Script Testing (bats) - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test bats tests/
  
  # 特定のテストファイルのみ実行
  cd docker/ubuntu-test && docker compose run ubuntu-test bats tests/example.bats
  
  # Shell Script Testing (bats) - macOS環境
  cd docker/macos-test && docker compose run macos-test bats tests/
  
  # Windows PowerShell Testing (Pester)
  docker compose run --rm windows-test
  

• 失敗理由が意図通りであることを確認

テストファイルの扱い:

• コード開発: 作成したテストファイルは最終成果物として残す（例: tests/*.bats）
• ドキュメント開発: 検証用のテストチェックリスト（TEST.md など）は、Greenフェーズ完了後に以下のいずれかを実施
  • 不要な場合は削除する
  • 継続的な品質確認が必要な場合は残す
  • 実装ガイドとして有用な場合は本体ドキュメントに統合する

2. Green（テストを通す）

• テストを通す最小限のコードを実装

• ハードコードや単純な実装でも可

• テストが全て通ることを確認

  # Shell Script Testing (bats) - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test bats tests/
  
  # Shell Script Testing (bats) - macOS環境
  cd docker/macos-test && docker compose run macos-test bats tests/
  
  # Windows PowerShell Testing (Pester)
  docker compose run --rm windows-test
  

• 新しいテストで既存テストが壊れていないか確認

3. Refactor（リファクタリング）

3.1. コード改善

• コードの重複を排除
• 命名を改善
• 設計パターンの適用
• パフォーマンス最適化

3.2. ローカルテスト実行

• テストが全て通り続けることを確認

  # Shell Script Testing (bats) - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test bats tests/
  
  # Shell Script Testing (bats) - macOS環境
  cd docker/macos-test && docker compose run macos-test bats tests/
  
  # Windows PowerShell Testing (Pester)
  docker compose run --rm windows-test
  

3.3. ローカルLint/Format実行

• Lintチェックを実行して警告がないことを確認

  # Shell Script Linting - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test lint-shell
  
  # Shell Script Linting - macOS環境
  cd docker/macos-test && docker compose run macos-test lint-shell
  

• Lintで問題がある場合には、コードフォーマットを適用する、個別に修正するなどして対応する

  # Shell Script Formatting (check) - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test shfmt -d -i 2 .
  
  # Shell Script Formatting (apply) - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test shfmt -i 2 -w .
  
  # Shell Script Formatting (check) - macOS環境
  cd docker/macos-test && docker compose run macos-test shfmt -d -i 2 .
  
  # Shell Script Formatting (apply) - macOS環境
  cd docker/macos-test && docker compose run macos-test shfmt -i 2 -w .
  

• Windows環境のPowerShell開発の場合: PSScriptAnalyzerによる静的解析を実行

  # Windows PowerShell Linting (PSScriptAnalyzer)
  # CIと同じ設定（PSGallery）で実行して警告がないことを確認
  docker compose run --rm windows-test-shell pwsh -Command \
    '$results = Invoke-ScriptAnalyzer -Path install/windows -Recurse -Settings PSGallery; if ($results) { $results | Format-Table -AutoSize; Write-Error "PSScriptAnalyzer found issues"; exit 1 } else { Write-Host "No issues found" -ForegroundColor Green }'
  

  • 警告が出た場合の対応:
    • 警告の原因を修正する
    • 正当な理由がある場合は SuppressMessageAttribute で抑制

• PSScriptAnalyzer警告の抑制例（Windows PowerShell開発時、正当な理由がある場合のみ）

  # 例: 複数形の関数名が意図的な場合
  function Install-Packages {
      [Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseSingularNouns', '',
          Justification='Packages refers to multiple items, plural is intentional')]
      param (
          [string]$PackageFile
      )
      # 実装...
  }
  
  # 例: 状態変更関数でShouldProcessが不要な場合
  function Set-GitConfig {
      [Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseShouldProcessForStateChangingFunctions', '',
          Justification='User consent implied by running script')]
      param()
      # 実装...
  }
  

• GitHub Actionsワークフローを修正した場合はActionLintを実行

  # GitHub Actions Linting - Ubuntu環境
  cd docker/ubuntu-test && docker compose run ubuntu-test actionlint
  
  # GitHub Actions Linting - macOS環境
  cd docker/macos-test && docker compose run macos-test actionlint
  

3.4. Git Commit & Push

• すべてのローカルチェックが通ったら、変更をコミット・プッシュ

  git add .
  git commit -m "type: description"
  git push
  

3.5. Pull Request 作成

• Pull Requestを作成（詳細は .claude/skills/pull-request/SKILL.md を参照）

  gh pr create --title "type: description" --body "..."
  

3.6. CI確認

• Pull Request作成後、GitHubでCI/CDパイプラインが自動実行される
• 以下のチェックが全て成功していることを確認:
  • Actionlint: GitHub Actions ワークフローファイルの構文チェック
  • ShellCheck + shfmt: シェルスクリプトの静的解析とフォーマットチェック
  • Test: プロジェクト固有のテスト実行
• CIが失敗した場合:
  1. PRページでログを確認してエラー原因を特定
  2. ローカルで同じコマンドを実行して再現
  3. 修正後、コミット・プッシュしてCIが再実行されるのを確認

テスト品質チェックポイント

出力形式

Red フェーズ

• 実装する機能の要件説明
• 作成したテストコード
• テスト実行結果（失敗の確認）

Green フェーズ

• 実装したコード
• テスト実行結果（成功の確認）
• 実装の説明

Refactor フェーズ

• リファクタリング内容の説明
• 改善後のコード
• ローカルテスト実行結果（引き続き成功の確認）
• ローカルLint/Formatチェック結果（全て通過）
• Git Commit & Push の実行
• Pull Request 作成
• CI結果の確認（PR作成後に自動実行、全てのチェックが成功）
• 改善のポイント

GitHub Actions CI

プロジェクトでは以下のCI/CDチェックが自動実行されます:

• Actionlint: GitHub Actions ワークフローファイルの構文チェック (actionlint.yml)
• ShellCheck + shfmt: シェルスクリプトの静的解析とフォーマットチェック (ci-macos.yml, ci-ubuntu.yml)
• Test: プロジェクト固有のテスト実行
  • macOS: ci-macos.yml
  • Ubuntu: ci-ubuntu.yml
  • Windows: ci-windows.yml

CI/CDパイプラインのURL: https://github.com/{owner}/{repo}/actions