Policy authors keep their Sentinel policies in a VCS-connected policy set repository. A recent merge contained a logic error that blocked many production runs. They want every pull request to that repository to prove each policy passes and fails on the right sample data. What should the repository's pipeline do?

The Sentinel CLI's sentinel test command runs test cases stored under test/POLICY_NAME/ next to each policy, each case supplying mock data and asserting the expected result of rules such as main. Policy authors write at least one passing and one failing case per policy, using mock data that HCP Terraform can generate from real runs through Download Sentinel mocks or the plan export API. Running sentinel test in the policy repository's pull request pipeline and requiring it to pass before merging catches logic errors before the VCS-connected policy set picks up the change. The same idea applies to OPA policies with opa test. terraform test runs .tftest.hcl files against Terraform configurations and modules; it does not load or evaluate Sentinel policies. Turning policies to advisory and watching production runs moves testing into production and still exposes every team to the faulty rule's output. terraform validate checks Terraform configuration syntax and internal consistency, and it cannot parse Sentinel code or detect logic errors in policy rules. Exam caveat: generated mock data can contain sensitive values from configuration, plan and state, so treat it carefully and prefer sanitised mocks in a shared repository. Operational check: open a pull request that deliberately inverts a rule and confirm the pipeline fails on the test case that expects the policy to fail.