Conftest Policy Unit Testing Prompt
Write unit tests for your Rego policies so Conftest rules are themselves covered by passing and failing fixtures before they gate real deployments.
- Target user
- Platform and security engineers maintaining policy-as-code repositories
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior policy-as-code engineer who treats Rego policies as production code that must
be unit-tested before it can block anyone's pipeline.
I will provide:
- One or more Rego policies used with Conftest (the `deny`/`warn`/`violation` rules).
- The input shape they evaluate (e.g. [TERRAFORM PLAN JSON / KUBERNETES MANIFEST / DOCKERFILE JSON]).
- Examples of configs that SHOULD pass and configs that SHOULD fail.
Your job:
1. **Map the rule surface** — list every `deny`/`warn` rule and the exact condition that triggers it,
so we know what behaviors need coverage.
2. **Write OPA test files** — produce `*_test.rego` with `test_` functions using `with input as {...}`
to inject fixtures. Cover: the violating case, the compliant case, and at least one boundary/edge case
per rule.
3. **Assert messages, not just counts** — check that the right denial message is returned, so a refactor
that silently changes which rule fires is caught.
4. **Avoid false confidence** — flag any rule with no negative test (a rule that has never been proven to
ALLOW a valid input is a rule that might block everything).
5. **Wire the runner** — give the `opa test` and `conftest verify` commands plus a CI step that fails the
build on any failing or uncovered rule.
6. **Suggest coverage gaps** — point out branches of the policy logic the current fixtures never exercise.
Output as: (a) the `*_test.rego` files, (b) a coverage table mapping each rule to its passing/failing tests,
(c) the CI commands, (d) a list of rules that still lack negative tests.
Do not weaken any policy to make a test pass. If a test reveals a real policy bug, describe the bug and
propose the fix separately so a human decides.
Why this prompt works
Policy-as-code has a quiet failure mode: the policy itself is untested. Teams write a Rego rule, watch it block one obviously-bad config, and ship it — never confirming that it allows good configs or that it fires for the right reason. The first time anyone learns the rule is too broad is when it blocks every legitimate deployment on a Friday. This prompt closes that gap by demanding both positive and negative fixtures for every rule, which is exactly the discipline OPA’s built-in opa test framework exists to support but that most teams skip.
The instruction to assert on denial messages rather than just counts is the part senior engineers appreciate. A test that only checks count(deny) == 1 passes even if a refactor makes the wrong rule fire. By pinning the expected message, you turn the test suite into living documentation of which rule owns which failure, so future edits can’t silently reshuffle responsibility. The explicit hunt for rules with no negative test is the highest-signal output here, because an unfalsified policy is the most dangerous kind: it looks like coverage but proves nothing.
Crucially, the prompt forbids the model from weakening a policy to make a test go green — the single most common way LLMs “fix” failing tests. Instead it must surface the real bug and let a human adjudicate, because relaxing a security control should never be a side effect of test maintenance. Pair this with the OPA and Conftest authoring prompt and the Checkov custom policy prompt for end-to-end policy coverage. See the full IaC category for related guardrail tooling.
Related prompts
-
Checkov Custom Policy Authoring Prompt
Write and test custom Checkov policies (YAML graph checks and Python checks) to enforce org-specific IaC guardrails across Terraform, CloudFormation, and Kubernetes — with suppressions, severities, and a CI gate that fails on real risk only.
-
Policy-as-Code with OPA & Conftest Prompt
Author Rego policies that gate IaC in CI — Conftest against Terraform plans, Kubernetes manifests, and Dockerfiles — with clear messages, exemptions, and a graduated enforce strategy that doesn't block every PR on day one.