Testing Packs
Pack testing should cover more than the function body.
At minimum, test:
- tool input and output shape
- error handling
- manifest consistency
- brokered external access where relevant
- runtime invocation after registration and attachment
Most pack failures are integration failures rather than algorithm failures. The tool logic might be correct while the manifest, broker policy, or attachment flow is wrong.
That is why meaningful pack testing has to cross the runtime boundary.
Test in the order the platform will use the pack
For most packs, a useful order is:
- tool contract tests
- manifest validation
- broker and connection-aware tests where relevant
- publication and registration checks
- workspace attachment and invocation checks
That order mirrors the way packs usually fail in the real system.