Studio and Providers
Test Studio HTTP wiring and keep provider integration tests focused.
Studio and provider tests are useful integration checks. Keep them narrow so they diagnose wiring and provider behavior without carrying all product correctness.
Test Studio Without Opening a Port
Studio exposes .fetch(...) for tests and internal tooling:
const studio = new Studio([agent]);
const response = await studio.fetch(
new Request("http://studio.test/agents/support/runs", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ message: "Hello" }),
}),
);
expect(response.status).toBe(200);Use this to verify agent registration, run request shape, sessions, traces, approval routes, and question routes.
Test Sessions and Traces
When a workflow depends on Studio persistence, check the store-facing behavior:
| Area | What to check |
|---|---|
| Sessions | create, append, list, get, and delete behavior |
| Traces | run status, observations, usage, metadata, and session linkage |
| Approvals | pending approval creation and approved or rejected decisions |
| Questions | pending question creation and answered question results |
Keep product auth and external notification policy outside Studio tests unless your application wrapper adds those behaviors.
Keep Provider Tests Focused
Provider integration tests should cover the behavior your workflow depends on:
- Test one happy path for each provider you support.
- Test tools and structured output where provider behavior matters.
- Test attachments only for provider models that support them.
- Record usage and trace ids so failures are diagnosable.
- Keep API keys in your normal secret system.
Avoid Broad Provider Suites
Do not use provider calls to test every branch of tool code, retrieval filtering, or application policy. Those branches should already be covered with direct tool, pipeline, wrapper, and retrieval tests.
Provider tests should answer a smaller question: does this model adapter behave the way this workflow requires?