Test Authorization
Authorization needs several kinds of evidence. Human review, Sekisho, generated validation, verify, application tests, and migration parity checks answer different questions. None substitutes for the others.
| Evidence | What it tells you | What it does not tell you |
|---|---|---|
| Tegata review | The specification expresses the authorization requirement the product intends. | That the application supplies the right data or enforces the result correctly. |
| Sekisho | Ninka's mechanically detectable schema and semantic checks pass. | That the underlying requirement is correct or that a human approved it. |
| Generated validation | Concrete cases derived from the current Tegata agree with the compiled policy. | That the Tegata matches the business requirement or a previous implementation. |
ninka-authz verify | The generated state at the resolved artifact and projection paths corresponds to the current source and satisfies Ninka's reproducibility and validation checks. | That Git tracks those files, that a human approved the change, or that behavior is unchanged from an earlier policy. |
| Application-boundary tests | The application constructs the intended input, calls the intended policy, and enforces the result correctly. | That the policy itself expresses the right business rule. |
| Migration parity | The old and new authorization systems agree on the cases you compared during migration. | That either system is independently correct for every possible input. |
1. Use generated validation to check the current policy
When compilation produces WASM, Ninka derives validation vectors from the current Tegata. An independent reference evaluator determines the expected decision, and the generated WASM is required to agree with it.
The vectors cover evidence such as positive allow witnesses, changes to individual facets, and allow/deny overlaps. They test Ninka's translation of the current specification. They are not a historical regression suite: if you intentionally change a rule, the next validation set is derived from the new Tegata.
Use the Authorization Reference to inspect these examples. The exact vector format and artifact fields belong to Generated Files.
2. Use verify as the reproducibility gate
npx ninka-authz verify
verify reads the current workspace and the generated files at the paths it resolves. It reproduces the source-derived state, checks the artifact bindings and hashes, replays validation against the execution bundle where required, and regenerates Consumer Projections for byte comparison.
verify does not inspect Git. Whether a generated file is tracked is a repository policy; whether the required file is present and matches the reproducible state is a verification fact. A workspace may intentionally ignore raw WASM and still pass verify when the bundle is present on disk.
A green run therefore means the state being checked is reproducible under the current Ninka/toolchain contract. It does not mean:
- a human approved the Tegata;
- the change preserves an earlier policy's behavior;
- Git contains a particular set of files.
The CLI Reference owns the exact checks, flags, skip behavior, and failure semantics. See CLI Reference.
3. Test the application boundary
Ninka cannot prove that a handler loaded the right domain data, constructed the intended authorization input, selected the intended policy, or actually enforced a deny. Test those responsibilities in the application.
At minimum, cover both sides of the boundary:
- the application passes the intended subject, action, and concrete resource to
check(); - the application handles the returned boolean correctly, including the deny path.
const check = vi.fn();
vi.mocked(createNinka).mockResolvedValue({ check } as never);
check.mockReturnValue(false);
const response = await POST(request);
expect(check).toHaveBeenCalledWith(policies.documentAccess, expectedInput);
expect(response.status).toBe(403);
check() is synchronous; only instance creation is awaited.
If your application wraps Ninka in its own composition root, test or mock that boundary instead of copying this example mechanically.
4. Test migrations against the system being replaced
Generated validation cannot establish parity with OPA, handwritten authorization, or another previous implementation because its expected results come from the current Tegata semantics.
During a migration, evaluate representative cases through both authorities and compare their decisions. Include allows, denies, boundary values, missing inputs, mixed-role subjects, and any legacy input conventions that matter to the old policy.
Keep that parity evidence separate from Ninka's generated validation. A zero-mismatch result is useful only if the expected policies and cases were actually exercised. See Migrate from OPA.
5. Human review remains a separate layer
Every mechanical check and application test can be green while the Tegata faithfully implements the wrong interpretation of a requirement.
Before accepting an authorization change, review the specification itself. See Review Authorization.