Testing
Testing
Test Anvia workflows without hiding application policy.
Anvia workflows are easiest to test when product code keeps clear boundaries: tools own side effects, agents own model behavior, pipelines own workflow shape, and the application wrapper owns persistence, logging, and error handling.
Use focused tests at each boundary before adding broad provider integration tests.
Testing Map
| Boundary | What to test | Page |
|---|---|---|
| Tools | input validation, expected product states, permission failures, output shape | Tools and Pipelines |
| Pipelines | deterministic step output, composition, batch behavior, concurrency limits | Tools and Pipelines |
| Agent wrappers | history persistence, trace metadata, usage records, runtime limits, known errors | Agents and Retrieval |
| Retrieval | embedding selectors, metadata filters, result ordering, dynamic context formatting | Agents and Retrieval |
| Evals | repeatable quality checks for functions, agents, and traced workflows | Evals |
| Studio | registration, HTTP run shape, sessions, traces, approvals, questions | Studio and Providers |
| Providers | one narrow happy path per provider and the behavior your workflow depends on | Studio and Providers |
Practical Rule
Most application correctness should be covered before a provider call is made. Use provider tests to verify integration behavior, not every branch of product policy.
Start Here
- Test tools and deterministic pipeline steps first.
- Test application wrappers around agents.
- Test retrieval filters without a model.
- Use Studio
.fetch(...)for local runtime wiring. - Keep provider integration tests narrow and explicit.