agentleFS
Sign inStart free
DevelopersGlobalDevelopersGlobal/ai-agent-skills/skills/integration-testing/SKILL.md

integration-testing

Skill216 starsChanged 6 months agoMITView on GitHub

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

We split this skill into the rules it gives an agent

8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After unit tests are passing

    line 15
  2. Distinctive:

    Before any feature ships to production

    line 16
  3. Distinctive:

    When testing database, API, or third-party service interactions

    line 17
  4. Distinctive:

    Use a real test database (not SQLite in-memory if prod uses PostgreSQL).

    line 31
  5. Distinctive:

    Use contract tests for external APIs — test against a recorded real response.

    line 32
  6. Distinctive:

    Use test containers for services that would otherwise require mocking.

    line 33
  7. Distinctive:

    Verify: No internal boundaries are mocked in integration tests.

    line 36
  8. Distinctive:

    Verify: Test suite passes when run in random order.

    line 52

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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)

ExcuseRebuttal
"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
  • references/testing-patterns.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free