Integration test
A test that runs several real pieces together, like your API route plus an actual database, to catch bugs that live in the seams.
See it
What it is
An integration test wires several real pieces together and checks that they cooperate: an API route plus a real database, a service plus the queue it publishes to, a form component plus the store behind it. The doubles come out at the seam you care about and the actual plumbing goes in. Everything else is negotiable: it is normal to run a real database while still faking Stripe, outbound email, and the SMS gateway, because isolation is a dial, not a switch.
This is where most real bugs hide, because most real bugs are seam bugs: a column renamed on one side, a JSON field that arrives as a string, a transaction that never commits. Typical setup is a throwaway database in Docker or Testcontainers, a fresh schema per run, and seeded fixtures. The 'testing trophy' crowd argues these deserve the biggest slice of your effort, precisely because they check behavior instead of implementation details.
Gotcha: speed and state. They take seconds instead of milliseconds, and if one test leaves rows behind, the next one fails for reasons that have nothing to do with its own code. Reset between tests or wrap each one in a transaction you roll back.
Ask AI for it
Write integration tests for the POST /orders endpoint using Vitest and Supertest, running against a real Postgres test database (Testcontainers or a dedicated test schema), not mocks. Migrate and seed before the suite. For per-test isolation, pick a mechanism this setup can actually support and say which one you picked: a transaction rollback only if the app and the test share one connection, otherwise a unique schema or database per test file, or deterministic cleanup that truncates the tables each test touched. Do not wrap a Supertest request in a test transaction when the server uses its own pool, since the request escapes it. Assert on both the HTTP response and the rows actually written, and include one failure case that must leave the database unchanged.