affaan-m/ECC

swift-protocol-di-testing

テスト可能なSwiftコードのためのプロトコルベースの依存性注入——焦点を絞ったプロトコルとSwift Testingを使用してファイルシステム、ネットワーク、外部APIをモックする。

66Collecting
See how to use itView GitHub source
npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/swift-protocol-di-testing"
Automated source guide

Source checked Jul 28, 2026·Refresh due Oct 26, 2026

Reorganized from the pinned upstream SKILL.md

Turn swift-protocol-di-testing's source instructions into a guide you can follow

According to the pinned SKILL.md from affaan-m/ECC: 外部の依存関係(ファイルシステム、ネットワーク、iCloud)を小さく焦点を絞ったプロトコルとして抽象化することで、SwiftコードをテストしやすくするパターンI/Oなしの決定論的テストをサポートする。

npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/swift-protocol-di-testing"
Check the pinned source

Best fit

  • テスト可能なSwiftコードのためのプロトコルベースの依存性注入——焦点を絞ったプロトコルとSwift Testingを使用してファイルシステム、ネットワーク、外部APIをモックする。

Bring this context

  • A concrete task that matches the documented purpose of swift-protocol-di-testing.
  • The files, examples, or context the task depends on.
  • Your constraints, target environment, and definition of done.

Expected outputs

  • A result that follows the pinned swift-protocol-di-testing instructions.
  • A concise record of assumptions, inputs used, and unresolved questions.
  • A final check against the source workflow and relevant permission signals.

Key source sections

Read swift-protocol-di-testing through these 5 source sections

Sections are extracted automatically from the pinned SKILL.md and link back to the source.

01

起動条件

ファイルシステム、ネットワーク、または外部APIにアクセスするSwiftコードを書く場合 実際の障害を起こさずにエラー処理パスをテストする必要がある場合 異なる環境(アプリ、テスト、SwiftUIプレビュー)で動作するモジュールを構築する場合 Swift並行処理(Actor、Sendable)をサポートするテスト可能なアーキテクチャを設計する場合

SKILL.md · 起動条件
ファイルシステム、ネットワーク、または外部APIにアクセスするSwiftコードを書く場合実際の障害を起こさずにエラー処理パスをテストする必要がある場合異なる環境(アプリ、テスト、SwiftUIプレビュー)で動作するモジュールを構築する場合
02

コアパターン

本番コードはデフォルト値を使用し、テストはモックを注入する。

SKILL.md · コアパターン
本番コードはデフォルト値を使用し、テストはモックを注入する。
03

1. 小さく焦点を絞ったプロトコルを定義する

Review the “1. 小さく焦点を絞ったプロトコルを定義する” section in the pinned source before continuing.

SKILL.md · 1. 小さく焦点を絞ったプロトコルを定義する
Review and apply the “1. 小さく焦点を絞ったプロトコルを定義する” source section.
04

2. デフォルト(本番用)実装を作成する

Review the “2. デフォルト(本番用)実装を作成する” section in the pinned source before continuing.

SKILL.md · 2. デフォルト(本番用)実装を作成する
Review and apply the “2. デフォルト(本番用)実装を作成する” source section.
05

3. テスト用のモック実装を作成する

Review the “3. テスト用のモック実装を作成する” section in the pinned source before continuing.

SKILL.md · 3. テスト用のモック実装を作成する
Review and apply the “3. テスト用のモック実装を作成する” source section.

SkillSignal prompt templates

Provide the task, context, and acceptance criteria

These prompts were written by SkillSignal from the source structure; they are not upstream text.

Task-start prompt

Confirm source fit, inputs, and outputs before acting.

Use swift-protocol-di-testing to help me with: [specific task]. Context: [files, data, or background]. Constraints: [environment, scope, and prohibited actions]. Before acting, check the pinned SKILL.md and explain which sections apply, what inputs are still missing, and what you will deliver.

Source-guided execution

Make the Agent explicitly follow the key extracted sections.

Apply the pinned swift-protocol-di-testing source to [task]. Pay particular attention to these source sections: “起動条件”, “コアパターン”, “1. 小さく焦点を絞ったプロトコルを定義する”, “2. デフォルト(本番用)実装を作成する”, “3. テスト用のモック実装を作成する”. Preserve the important decision at each step. Mark facts not covered by the source as “needs confirmation” instead of inventing them. Then verify the result against my acceptance criteria: [criteria].

Result-review prompt

Check omissions, permissions, and source drift before delivery.

Review the current swift-protocol-di-testing result: (1) does it satisfy the original task; (2) were any applicable steps or limits in the pinned SKILL.md missed; (3) did it perform any unauthorized file, command, network, or data action; and (4) which conclusions remain unverified? List issues first, then fix only what the source or user authorization supports.

Output checklist

Verify each item before delivery

The task matches the purpose documented in the SKILL.md.

The source section “起動条件” has been checked.

The source section “コアパターン” has been checked.

The source section “1. 小さく焦点を絞ったプロトコルを定義する” has been checked.

The source section “2. デフォルト(本番用)実装を作成する” has been checked.

Inputs, constraints, and acceptance criteria are explicit.

Unverified facts, compatibility, and outcome claims are clearly marked.

Any file, command, network, or data action has been reviewed.

Choose a different workflow

When another Skill is the better fit

FAQ

What does swift-protocol-di-testing do?

外部の依存関係(ファイルシステム、ネットワーク、iCloud)を小さく焦点を絞ったプロトコルとして抽象化することで、SwiftコードをテストしやすくするパターンI/Oなしの決定論的テストをサポートする。

How do I start using swift-protocol-di-testing?

The catalog detected this source-specific install command: npx skills add https://github.com/affaan-m/ECC --skill "docs/ja-JP/skills/swift-protocol-di-testing". Inspect the command and pinned source before running it.

Which Agent platforms does it declare?

No dedicated Agent platform is declared in the pinned source record.

Repository stars
234,327
Repository forks
35,711
Quality
66/100
Source repository last pushed

Quality breakdown

Based on traceable docs and repository signals; stars are not treated as quality.

66/100
Documentation23/30
Specificity11/25
Maintenance20/20
Trust signals12/25

Compare before choosing

Related Agent Skills and source variants

These links are selected from shared tasks, functions, stacks, platforms, and same-name variants. Compare the source owner, documentation, permissions, and maintenance signals.

View original Skill.mdThis page is parsed directly from the repository SKILL.md without editorial rewriting. Collected: Jul 28, 2026 · about 1 min

プロトコルベースのSwift依存性注入テスト

外部の依存関係(ファイルシステム、ネットワーク、iCloud)を小さく焦点を絞ったプロトコルとして抽象化することで、SwiftコードをテストしやすくするパターンI/Oなしの決定論的テストをサポートする。

起動条件

  • ファイルシステム、ネットワーク、または外部APIにアクセスするSwiftコードを書く場合
  • 実際の障害を起こさずにエラー処理パスをテストする必要がある場合
  • 異なる環境(アプリ、テスト、SwiftUIプレビュー)で動作するモジュールを構築する場合
  • Swift並行処理(Actor、Sendable)をサポートするテスト可能なアーキテクチャを設計する場合

コアパターン

1. 小さく焦点を絞ったプロトコルを定義する

各プロトコルは1つの外部関心事のみを処理する。

// File system access
public protocol FileSystemProviding: Sendable {
    func containerURL(for purpose: Purpose) -> URL?
}

// File read/write operations
public protocol FileAccessorProviding: Sendable {
    func read(from url: URL) throws -> Data
    func write(_ data: Data, to url: URL) throws
    func fileExists(at url: URL) -> Bool
}

// Bookmark storage (e.g., for sandboxed apps)
public protocol BookmarkStorageProviding: Sendable {
    func saveBookmark(_ data: Data, for key: String) throws
    func loadBookmark(for key: String) throws -> Data?
}

2. デフォルト(本番用)実装を作成する

public struct DefaultFileSystemProvider: FileSystemProviding {
    public init() {}

    public func containerURL(for purpose: Purpose) -> URL? {
        FileManager.default.url(forUbiquityContainerIdentifier: nil)
    }
}

public struct DefaultFileAccessor: FileAccessorProviding {
    public init() {}

    public func read(from url: URL) throws -> Data {
        try Data(contentsOf: url)
    }

    public func write(_ data: Data, to url: URL) throws {
        try data.write(to: url, options: .atomic)
    }

    public func fileExists(at url: URL) -> Bool {
        FileManager.default.fileExists(atPath: url.path)
    }
}

3. テスト用のモック実装を作成する

public final class MockFileAccessor: FileAccessorProviding, @unchecked Sendable {
    public var files: [URL: Data] = [:]
    public var readError: Error?
    public var writeError: Error?

    public init() {}

    public func read(from url: URL) throws -> Data {
        if let error = readError { throw error }
        guard let data = files[url] else {
            throw CocoaError(.fileReadNoSuchFile)
        }
        return data
    }

    public func write(_ data: Data, to url: URL) throws {
        if let error = writeError { throw error }
        files[url] = data
    }

    public func fileExists(at url: URL) -> Bool {
        files[url] != nil
    }
}

4. デフォルトパラメーターで依存関係を注入する

本番コードはデフォルト値を使用し、テストはモックを注入する。

public actor SyncManager {
    private let fileSystem: FileSystemProviding
    private let fileAccessor: FileAccessorProviding

    public init(
        fileSystem: FileSystemProviding = DefaultFileSystemProvider(),
        fileAccessor: FileAccessorProviding = DefaultFileAccessor()
    ) {
        self.fileSystem = fileSystem
        self.fileAccessor = fileAccessor
    }

    public func sync() async throws {
        guard let containerURL = fileSystem.containerURL(for: .sync) else {
            throw SyncError.containerNotAvailable
        }
        let data = try fileAccessor.read(
            from: containerURL.appendingPathComponent("data.json")
        )
        // Process data...
    }
}

5. Swift Testingを使用してテストを書く

import Testing

@Test("Sync manager handles missing container")
func testMissingContainer() async {
    let mockFileSystem = MockFileSystemProvider(containerURL: nil)
    let manager = SyncManager(fileSystem: mockFileSystem)

    await #expect(throws: SyncError.containerNotAvailable) {
        try await manager.sync()
    }
}

@Test("Sync manager reads data correctly")
func testReadData() async throws {
    let mockFileAccessor = MockFileAccessor()
    mockFileAccessor.files[testURL] = testData

    let manager = SyncManager(fileAccessor: mockFileAccessor)
    let result = try await manager.loadData()

    #expect(result == expectedData)
}

@Test("Sync manager handles read errors gracefully")
func testReadError() async {
    let mockFileAccessor = MockFileAccessor()
    mockFileAccessor.readError = CocoaError(.fileReadCorruptFile)

    let manager = SyncManager(fileAccessor: mockFileAccessor)

    await #expect(throws: SyncError.self) {
        try await manager.sync()
    }
}

ベストプラクティス

  • 単一責任:各プロトコルは1つの関心事を処理する——多くのメソッドを持つ「ゴッドプロトコル」を作らない
  • Sendable 一貫性:プロトコルがActor境界をまたいで使用される場合に必要
  • デフォルトパラメーター:本番コードは実際の実装をデフォルトで使用する。テストだけがモックを指定する必要がある
  • エラーのモック:障害パスをテストするために設定可能なエラープロパティを持つモックを設計する
  • 境界のみをモック:外部の依存関係(ファイルシステム、ネットワーク、API)をモックし、内部型はモックしない

避けるべきアンチパターン

  • すべての外部アクセスをカバーする単一の大きなプロトコルを作成する
  • 外部の依存関係を持たない内部型をモックする
  • 適切な依存性注入の代わりに #if DEBUG 条件文を使用する
  • Actorと組み合わせて使用する際に Sendable 一貫性を忘れる
  • 過度な設計:型が外部の依存関係を持たない場合、プロトコルは必要ない

使用場面

  • ファイルシステム、ネットワーク、または外部APIに触れるあらゆるSwiftコード
  • 実際の環境では引き起こすことが難しいエラー処理パスをテストする場合
  • アプリ、テスト、SwiftUIプレビューのコンテキストで動作するモジュールを構築する場合
  • Swift並行処理(Actor、構造化並行処理)を採用したテスト可能なアーキテクチャが必要なアプリ
Source repo
affaan-m/ECC
Skill path
docs/ja-JP/skills/swift-protocol-di-testing/SKILL.md
Commit SHA
4e973d3eaf92
Repository license
MIT
Data collected