testing-ops

テストのパターン

言語を問わず適用できる、普遍的なテスト戦略とパターンです。

テストピラミッド

        /\
       /  \     E2E Tests (few, slow, expensive)
      /    \    - Full system tests
     /------\   - Real browser/API calls
    /        \
   /  Integ   \ Integration Tests (some)
  /   Tests    \ - Service boundaries
 /--------------\ - Database, APIs
/                \
/   Unit Tests    \ Unit Tests (many, fast, cheap)
------------------  - Single function/class
                    - Mocked dependencies

テストの種類

単体テスト

Scope:      Single function/method/class
Speed:      Milliseconds
Dependencies: All mocked
When:       Every code change
Coverage:   80%+ of codebase

統合テスト

Scope:      Multiple components together
Speed:      Seconds
Dependencies: Real databases, mocked external APIs
When:       PR/merge, critical paths
Coverage:   Key integration points

エンドツーエンドテスト

Scope:      Full user journey
Speed:      Minutes
Dependencies: Real system (or staging)
When:       Pre-deploy, nightly
Coverage:   Critical user flows only

テストの命名規則

test_<unit>_<scenario>_<expected>

Examples:
- test_calculate_total_with_discount_returns_reduced_price
- test_user_login_with_invalid_password_returns_401
- test_order_submit_when_out_of_stock_raises_error

準備・実行・検証（AAA）

def test_calculate_discount():
    # Arrange - Set up test data and dependencies
    cart = Cart()
    cart.add_item(Item(price=100))
    discount = Discount(percent=10)

    # Act - Execute the code under test
    total = cart.calculate_total(discount)

    # Assert - Verify the results
    assert total == 90

テストダブル

種類	目的	例
スタブ	用意されたデータを返す	stub.get_user.returns(fake_user)
モック	インタラクションを検証する	mock.send_email.assert_called_once()
スパイ	呼び出しを記録し、実際の実装を使用する	spy.on(service, 'save')
フェイク	簡略化された動作する実装	実際の DB の代わりに FakeDatabase() を使用
ダミー	プレースホルダー。使用されない	必須パラメーター用の null オブジェクト

テストの分離戦略

データベースの分離

Option 1: Transaction rollback (fast)
- Start transaction before test
- Rollback after test

Option 2: Truncate tables (medium)
- Clear all data between tests

Option 3: Separate database (slow)
- Each test gets fresh database

外部サービスの分離

Option 1: Mock at boundary
- Replace HTTP client with mock

Option 2: Fake server
- WireMock, MSW, VCR cassettes

Option 3: Contract testing
- Pact, consumer-driven contracts

テスト対象

必ずテストする

• ビジネスロジックと計算
• 入力検証とエラー処理
• セキュリティ上重要なコード（認証、権限）
• エッジケースと境界条件

テストすることが望ましい

• 統合ポイント（DB、API）
• 状態遷移
• 設定の処理

テストを避ける

• フレームワークの内部
• サードパーティーライブラリの動作
• 単純なゲッター／セッター
• プライベートな実装の詳細

テスト品質チェックリスト

• テストは独立している（実行順序に依存しない）
• テストは決定的である（不安定なテストがない）
• テストは高速である（単体テストは 100ms 未満、統合テストは 5s 未満）
• テスト名は明確で、動作を説明している
• 正常系とエラーケースの両方を網羅している
• テストで本番ロジックを繰り返していない
• モックは最小限である（外部との境界のみ）

追加リソース

• ./references/tdd-workflow.md - テスト駆動開発のサイクル
• ./references/mocking-strategies.md - モックを使うタイミングと方法
• ./references/test-data-patterns.md - フィクスチャ、ファクトリー、ビルダー
• ./references/ci-testing.md - CI/CD パイプラインでのテスト

スクリプト

• ./scripts/coverage-check.sh - カバレッジを測定し、しきい値を下回った場合に失敗させます