integration-test

A seam is where your code hands work to something it does not own — a database, a broker, a cache, another team's API. Unit tests stop at the seam and mock what is on the far side, so everything they prove is a statement about your own mock. This skill writes the tests that cross it and run against the real thing.

Real infrastructure makes tests slow and flaky unless they are hermetic: each test brings its own data, leaves nothing behind, and passes alone, shuffled, and twice in a row. A suite without that property gets marked skip within a month. Both halves are the job — cross the seam, and stay hermetic while doing it.

What this skill writes

New test files, the harness that starts the real dependencies, and one report. The production code stays as it is: a test that can only pass after the source changes has found a bug, and that goes in the report as a finding for its owner.

1. Inventory the seams

Read the wiring, not the whole codebase: where clients are constructed, what the config and environment variables name, what the container or compose files declare, what the manifest lists as a driver or SDK.

Seam	Looks like
Database	a connection string, an ORM, a migration folder, raw SQL
Cache	Redis, Memcached, a client with a TTL
Broker or stream	Kafka, RabbitMQ, SQS, NATS, an outbox table
Object store	S3, GCS, Azure Blob, a signed-URL helper
Third-party API	an SDK, a base URL in config, a webhook receiver
Another service you own	an internal base URL, a generated client
Filesystem	a path from config, a temp directory, an upload folder

Rank them the same way risk is ranked anywhere: what the seam decides — money, permissions, data writes — and how often the code around it changes:

git log --since='6 months ago' --name-only --format= -- <path> | grep . | sort | uniq -c | sort -rn

The grep . matters: --name-only prints a blank line between commits, and without it the blank sorts to the top as your busiest file.