In Gatekeeper's gator verify, what can a Suite case assert beyond a plain denial?

## The Suite file Where `gator test` answers "do these manifests pass these rules right now", `gator verify` is the assertion harness: a checked-in test suite for a constraint, written as a Kubernetes-shaped document. A `Suite` (`apiVersion: test.gatekeeper.sh/v1alpha1`, `kind: Suite`) holds a list of `tests`. Each test names the `template` and `constraint` files it exercises, and holds a list of `cases`. Each case names an `object` file — one manifest to review — and a list of `assertions` about the result. Paths are relative to the suite file, so a suite plus its fixture files is a self-contained directory in the rule repository. ## What an assertion can pin - **`violations`** — `no` for the allow case, `yes` for a denial, or an integer when the count itself is the thing you care about. A rule that walks a list of containers can easily produce one violation per container; asserting an exact count is how you notice it produced three when the object has one offending container. - **`message`** — the violation's message must match the text you give. This is the assertion that turns "something was rejected" into "the rule I meant rejected it, for the reason I meant, with wording a developer can act on". A case may carry more than one assertion, which is how you say "exactly one violation, and its message mentions the PodDisruptionBudget". ## Why `violations: yes` alone is a weak test Consider the availability rule: any Deployment above one replica must be covered by a PodDisruptionBudget. Suppose a refactor introduces a typo in the parameter lookup, and the rule now denies every Deployment it sees, whatever its replica count and whatever budgets exist. Every deny case still passes. The suite goes green. Only the allow case — a single-replica Deployment that must not be flagged — and a message assertion catch it, because the message the broken rule emits is not the message you asserted. The same trap appears when one template grows several distinct denials. Without a message assertion, a case can pass because a completely different branch of the rule fired, and you have unknowingly stopped testing the branch you thought you were testing. ## Cases that need cluster state An admission review carries the object under review and nothing else — no siblings, no cluster inventory, no history. A rule like the PodDisruptionBudget one is *referential*: to decide, it needs to know which budgets exist. In a cluster that state is replicated into the engine; offline it has to come from fixtures, and a case's `inventory` field is where those manifests go. That makes the referential case honest in both directions: one fixture set where a matching budget exists (allow) and one where it does not (deny). Forget the inventory and your "deny" case may pass for the wrong reason — the rule found nothing because you gave it nothing. ## Suite hygiene - Give every test and case a `name`. When CI fails, the name is the whole error message a reviewer reads first. - Keep the allow cases. A suite of deny cases only proves the rule can say no, never that it can say yes, and a rule that denies everything is the fastest way to have your guardrail switched off by an angry platform team. - Assert the message on the cases a human will actually hit. The message is the product: it is what appears in a developer's terminal at 5pm when their deploy is rejected. - Keep the suite next to the template and constraint it tests, so a change to the rule and a change to its proof arrive in the same review. ## Where it runs `gator verify` over the suite directory is a pre-merge check on the rule repository. No cluster, no kubeconfig, no credentials: the suite, the fixtures and the rules are all files. That is what lets a constraint change be reviewed like ordinary code — with a diff, a test run and a red build when the proof breaks.