You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
Why test rejection as well as success?
Success-only examples miss over-broad access, swallowed errors and lost updates.
Four tests for the same report
| Condition | Observable result |
|---|---|
| Authorized caller, valid report | Correct content and path |
| Missing report | Distinguishable not-found outcome |
| Read-only caller attempts mutation | Rejection and unchanged state |
| Two writers use the same old version | Declared concurrency behavior without silent lost updates |
Rejection alone is insufficient: an implementation that rejects everything can pass many malformed-input tests. Pair acceptance and rejection, then inspect the actual observable state.
Challenge the test too
Deliberately break an implementation by duplicating a mount prefix, ignoring a version or swallowing an error. The relevant check should detect it. This helps expose tests that always pass.
External services still require integration evidence; cross-process semantics require independent processes. Do not turn a narrower conformance result into a broader deployment guarantee.
Check your understanding
Why test rejection as well as success?
Success-only examples miss over-broad access, swallowed errors and lost updates.
Continue along a learning path
- Build and check a providerStep 6 of 6
Referenced here
Terms
- AFS
AFS (Agentic File System) turns the files, services, and active work relevant to a task into an inspectable resource view. Instead of handing an agent an undifferentiated machine or a pile of APIs, it gives the task a world with names and boundaries.