‹ 首页

integration-testing

@developersglobal · 收录于 1 周前

Test real system boundaries, not mocks of mocks. Integration tests verify that components work together, not that they work in isolation.

场景集成测试接口联调上线前检查

适合你，如果厌倦了纯单元测试，想验证组件间真实协作

/ 下载安装
integration-testing.skill双击,或拖进 Claude 桌面版 / Cowork,即完成安装↓ .skill↓ .zip
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code~/.claude/skills/(项目级 .claude/skills/)
Codex CLI~/.codex/skills/
Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add developersglobal/ai-agent-skills/integration-testing
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- developersglobal/ai-agent-skills/integration-testing
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify developersglobal/ai-agent-skills/integration-testing
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
64GitHub stars
~631上下文体积 · 单文件
镜像托管

怎么用

技能原文 SKILL.md作者撰写 · MIT · f47f948
Overview

Unit tests verify components work in isolation. Integration tests verify they work together. The gap between these two is where most production bugs hide. This skill ensures integration tests cover the real system boundaries.

When to Use
  • After unit tests are passing
  • Before any feature ships to production
  • When testing database, API, or third-party service interactions
Process
Step 1: Identify Real Boundaries
  1. Map every boundary in the system: code ↔ database, code ↔ external API, service ↔ service, frontend ↔ backend.
  2. Rank boundaries by failure impact.
  3. Integration tests should cover the top 5 highest-impact boundaries.

Verify: Boundary map created. Top 5 prioritized.

Step 2: Test Real, Not Mocked
  1. Use a real test database (not SQLite in-memory if prod uses PostgreSQL).
  2. Use contract tests for external APIs — test against a recorded real response.
  3. Use test containers for services that would otherwise require mocking.
  4. Mock only: third-party services you can't control, slow services with contract tests already in place.

Verify: No internal boundaries are mocked in integration tests.

Step 3: Test the Happy Path AND Failure Cases
  1. Happy path: the system works end-to-end for the primary use case.
  2. Failure cases: database down, API returns 500, timeout, malformed response.
  3. State verification: after each action, verify the state in the real database.

Verify: At least 1 failure case per boundary is tested.

Step 4: Keep Tests Independent
  1. Each test cleans up its own state (transactions rolled back, test data deleted).
  2. Tests don't share state with each other.
  3. Tests can run in any order.

Verify: Test suite passes when run in random order.

Common Rationalizations (and Rebuttals)

| Excuse | Rebuttal | |--------|----------| | "Unit tests are enough" | Unit tests with mocks test that your mocks work, not your system. | | "Integration tests are slow" | Slow tests are better than discovering bugs in production. Optimize the setup, not the coverage. | | "We test in staging" | Staging is not a substitute for automated tests. It's too slow and too manual. |

Verification
  • [ ] Real boundaries identified and prioritized
  • [ ] Integration tests use real dependencies (not mocks of internal components)
  • [ ] Happy path and failure cases tested for each boundary
  • [ ] Tests are independent (can run in any order)
  • [ ] Test cleanup is reliable
References
  • [test-driven-development skill](../test-driven-development/SKILL.md)
  • [references/testing-patterns.md](../../references/testing-patterns.md)
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…