Skip to main content
Integration Tests page with assembled chains

​
What Integration Tests Are

An integration test runs a sequence of endpoints as one workflow, with each step using data from the one before:
TestSprite identifies these handoffs and runs the chain end to end as a single test. Dynamic Variables shows the captured values; Dependency Chains explains how the run order is determined.

​
Where Integration Tests Live in the UI

Integration tests have their own sidebar row, Test Cases → Integration Tests, next to Endpoint Tests. From there you can:
  • Browse the auto-assembled chains and open any one to see its steps
  • Run all chains from the toolbar, or open a chain and rerun it on its own
  • Refine a chain in chat (add a step, drop a step, change the sequence)

​
Why Integration Tests Matter

Endpoint tests verify each step in isolation; integration tests verify the handoffs. They catch the “individual endpoints work but the system doesn’t” bugs:

​
Per-Chain View

Click into an integration test to see its detail page:
An integration test detail page — its five chained steps beside the assembled code

​
When a Chain Fails

Chains fail in three distinguishable ways:
Integration test detail page with step list
See Endpoint Tests for how Blocked differs from Failed.

​
Auto Cleanup Pairing

After every run or rerun, even a passing one, TestSprite removes the records your chains created (users, orders, sessions), so the next run starts from a known-empty state. See Auto Cleanup. UI testing has the same idea, a use case with multiple steps, but runs browser actions instead of HTTP calls. See UI Testing.

​
Edge Cases & Troubleshooting

Common when your API is mostly read-only or the initial plan had sparse hints. Re-run plan generation with a hint like “Generate integration chains that exercise create → read → update → delete on /orders”, or ask for specific multi-step flows in chat.
Open the chain and describe the right shape in chat: “The right order is POST /users → POST /sessions → POST /orders, not /users → /orders directly”. TestSprite re-runs with the corrected sequence.
A later step needs a value no earlier step provided. Common causes:
  • Naming mismatch: an earlier step produces user_id but the later step references userId. Refine in chat to align the names.
  • Missing field: the producer step Passed but its response didn’t include the field. Check its response in Stdout and refine to capture from a different field.
Add a wait in chat: “After the POST step, wait 250ms before the GET”.
The step has a side effect the chain didn’t account for, such as leaving a session active. Refine the step to clean up after itself, or add an explicit cleanup step: “After the GET step, DELETE the session created in step 2”.

​
Where to Go Next

Dynamic Variables

Where captured values surface in the UI

Dependency Chains

How run order is determined

Auto Cleanup

Records created during a run get deleted afterward