# Integration Tests

> Create narrow tests through a real adapter or boundary using its public interface. Use for database, HTTP-client, message-adapter or filesystem contracts; use `e2e-tests` when proving the flow requires booting the assembled application.

- Skill: `navikt/integration-tests` (Agent Skill)
- Install (CLI): `npx skillmds@latest add navikt/integration-tests`
- Raw SKILL.md: https://api.skillmd.com/api/skills/navikt/integration-tests/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: navikt (https://skillmd.com/u/navikt)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/navikt/integration-tests

---


# Integration Tests

Exercise the smallest real boundary that can prove the contract. Discover the
repository's stack and test conventions before choosing frameworks, fixtures,
or commands.

## 1. Discover the test contract

Inspect neighboring integration or adapter tests, build manifests, test-runner
configuration, fixture helpers, and CI commands. Record:

- the test framework and local style;
- how the target adapter is constructed;
- how external dependencies are provisioned and reset;
- the focused and broader test commands;
- how this repository distinguishes integration tests from E2E tests.

Do not assume Gradle, Kotest, Ktor, Testcontainers, Postgres, Flyway, Exposed,
or any named fixture until repository evidence establishes it. If no convention
exists, propose the smallest option compatible with the detected stack and get
approval before adding dependencies or build configuration.

## 2. Choose the seam

- Test behavior through a public repository, adapter, client, or application
  interface.
- Use the real boundary only where a fake would hide serialization, query,
  protocol, migration, transaction, or lifecycle behavior.
- Avoid full application boot; that belongs in `e2e-tests`.
- Keep fixture state deterministic: initialize once at the appropriate scope,
  reset between cases, and close resources reliably.
- Use synthetic data without real personal data or secrets.

## 3. Implement and verify

Follow the discovered framework, naming, directory, lifecycle, and helper
patterns. Run the exact focused command, then the proportionate broader test
gate. Report commands, exit codes, and relevant output. Completion requires
fresh evidence that the real boundary was exercised through the public seam.