iOS Test Design（iOSテスト設計支援）

概要

XCTestおよびXCUITestを活用したiOSアプリケーションのテスト設計を支援するスキル。 デトロイト学派寄りのアプローチを採用し、実際のコンポーネント連携をテストすることで、信頼性の高いテストスイートを構築する。

対象範囲

• Unit Test: XCTestによる単体テスト設計
• Integration Test: コンポーネント間連携テスト
• UI Test: XCUITestによるUIテスト設計
• テストダブル: モック/スタブ/フェイク/スパイの設計
• テストデータ: フィクスチャ、ファクトリ、シード管理

実行条件

以下の状況でこのスキルを起動する：

• iOSアプリのテスト設計・実装を行う時
• 既存テストのリファクタリングを検討する時
• テストカバレッジを向上させたい時
• テストダブル（モック/スタブ）の設計を相談したい時
• テスト戦略を立案したい時
• テストの保守性・可読性を改善したい時

プロセス

Phase 1: テスト対象の分析

1.1 対象コードの理解

1. テスト対象のクラス/構造体/関数を特定
2. 依存関係を洗い出す
3. 公開インターフェースを確認
4. 副作用（ネットワーク、永続化、通知等）を特定

1.2 テスト可能性の評価

Phase 2: テスト戦略の策定

2.1 テストピラミッドの設計

        ╱╲
       ╱  ╲     E2E Test（XCUITest）: 主要シナリオのみ
      ╱────╲
     ╱      ╲   Integration Test: コンポーネント間連携
    ╱────────╲
   ╱          ╲ Unit Test: ビジネスロジック中心
  ╱────────────╲

2.2 テストレベル別の方針

Phase 3: XCTestによるUnitテスト設計

詳細は

references/xctest-patterns.md

3.1 テストケースの構造

final class SampleTests: XCTestCase {
    
    // MARK: - Properties
    private var sut: SystemUnderTest!
    private var mockDependency: MockDependency!
    
    // MARK: - Setup/Teardown
    override func setUp() {
        super.setUp()
        mockDependency = MockDependency()
        sut = SystemUnderTest(dependency: mockDependency)
    }
    
    override func tearDown() {
        sut = nil
        mockDependency = nil
        super.tearDown()
    }
    
    // MARK: - Tests
    func test_methodName_condition_expectedBehavior() {
        // Given（前提条件）
        let input = ...
        
        // When（実行）
        let result = sut.method(input)
        
        // Then（検証）
        XCTAssertEqual(result, expected)
    }
}

3.2 命名規則

test_<対象メソッド>_<条件>_<期待される振る舞い>

例:
test_login_withValidCredentials_returnsSuccess
test_fetchUser_whenNetworkError_throwsError
test_calculate_withNegativeInput_returnsZero

Phase 4: テストダブルの設計

詳細は

references/test-doubles.md

4.1 テストダブルの種類と使い分け

stub.returnValue = expectedData

XCTAssertTrue(mock.didCallMethod)

InMemoryUserRepository

spy.calledArguments

4.2 プロトコルベースのテストダブル

// 抽象化されたプロトコル
protocol UserRepositoryProtocol {
    func fetch(id: String) async throws -> User
}

// 本番実装
final class UserRepository: UserRepositoryProtocol { ... }

// テストダブル
final class MockUserRepository: UserRepositoryProtocol {
    var fetchResult: Result<User, Error> = .success(User.stub)
    var fetchCallCount = 0
    var lastFetchedId: String?
    
    func fetch(id: String) async throws -> User {
        fetchCallCount += 1
        lastFetchedId = id
        return try fetchResult.get()
    }
}

Phase 5: XCUITestによるUIテスト設計

詳細は

references/xcuitest-patterns.md

5.1 Page Objectパターン

// Page Object
final class LoginPage {
    private let app: XCUIApplication
    
    var emailField: XCUIElement { app.textFields["email"] }
    var passwordField: XCUIElement { app.secureTextFields["password"] }
    var loginButton: XCUIElement { app.buttons["login"] }
    
    init(app: XCUIApplication) {
        self.app = app
    }
    
    func login(email: String, password: String) -> HomePage {
        emailField.tap()
        emailField.typeText(email)
        passwordField.tap()
        passwordField.typeText(password)
        loginButton.tap()
        return HomePage(app: app)
    }
}

5.2 Accessibility Identifierの設計

<screen>_screen

login_screen

<action>_button

submit_button

<field>_field

email_field

<content>_label

error_label

<item>_cell_<index>

user_cell_0

Phase 6: テストデータ管理

詳細は

references/test-data.md

6.1 Factoryパターン

enum UserFactory {
    static func make(
        id: String = UUID().uuidString,
        name: String = "Test User",
        email: String = "test@example.com",
        isActive: Bool = true
    ) -> User {
        User(id: id, name: name, email: email, isActive: isActive)
    }
    
    static var activeUser: User { make(isActive: true) }
    static var inactiveUser: User { make(isActive: false) }
}

6.2 フィクスチャファイル

Tests/
├── Fixtures/
│   ├── JSON/
│   │   ├── user_response.json
│   │   └── error_response.json
│   └── Stubs/
│       └── UserStub.swift

Phase 7: テストカバレッジ分析

7.1 カバレッジ目標

7.2 Xcodeでのカバレッジ確認

1. スキーム設定 → Test → Options → Code Coverage有効化

2. Cmd + U

   でテスト実行
3. Report Navigator → Coverage でレポート確認

7.3 カバレッジ改善の優先順位

1. ビジネスロジック: Domain層、UseCase層
2. 状態管理: ViewModel、Reducer
3. データ変換: Mapper、Parser、Formatter
4. エラーハンドリング: 例外処理、リトライロジック

出力形式

テスト設計ドキュメント

# テスト設計書: <機能名>

## 1. テスト対象
- クラス/構造体: `ClassName`
- 責務: 〇〇を行う

## 2. テスト戦略
- テストレベル: Unit / Integration / UI
- テストダブル: 使用する依存のリスト

## 3. テストケース一覧
| ID | カテゴリ | テスト内容 | 期待結果 |
|----|---------|----------|---------|
| TC-001 | 正常系 | ... | ... |
| TC-002 | 異常系 | ... | ... |

## 4. テストダブル設計
- MockXxx: 〇〇の呼び出しを検証
- StubYyy: 〇〇の値を返す

## 5. テストデータ
- Factory: XxxFactory
- Fixture: xxx_response.json

テストコード

import XCTest
@testable import TargetModule

final class FeatureTests: XCTestCase {
    // 上記パターンに従ったテストコード
}

ガードレール

必須遵守事項

1. テストの独立性: 各テストは他のテストに依存しない
2. テストの決定論性: 同じ条件で常に同じ結果
3. テストの高速性: Unitテストは1秒以内に完了
4. 明確な命名: テスト名から内容が分かる

禁止事項

1. 本番コードのテスト用変更: テストのために本番コードにテスト用分岐を入れない
2. ネットワーク依存: Unitテストで実ネットワークアクセスしない
3. 時間依存:

   Date()

   直接使用ではなく注入する
4. グローバル状態: シングルトンの直接参照を避ける

警告事項

1. 過度なモック: 全てをモックすると実装詳細への依存が増す
2. テストの重複: 同じ振る舞いを複数箇所でテストしない
3. 実装の検証: 「どう動くか」ではなく「何をするか」をテスト

参照

• references/xctest-patterns.md

  : XCTestパターン集

• references/xcuitest-patterns.md

  : XCUITestパターン集

• references/test-doubles.md

  : テストダブル設計ガイド

• references/test-data.md

  : テストデータ管理ガイド