Skip to main content
Glama

Run Rego tests

rego_test
Read-onlyIdempotent

Run Rego unit tests with opa test to validate policy logic. Get aggregate pass/fail counts, filter by test name regex, and enforce minimum coverage thresholds.

Instructions

Run Rego unit tests with opa test. Returns aggregate pass/fail counts plus per-test records. Tests live in *_test.rego files; rule names beginning with test_ are picked up automatically. Use runPattern to filter by name regex; when no tests match, the error hint includes the pattern you supplied. Use threshold to gate on minimum coverage (returns COVERAGE_BELOW_THRESHOLD on failure). Use varValues: true with verbose: true to include local variable bindings in the trace -- essential for debugging table-driven tests written with every tc in cases { ... } to identify which case caused a failure. When tests use the test_X[case] parametrized form, the output includes parameterizedGroups mapping each base test name to its case records. Use ignorePatterns to exclude generated or fixture files. Use bundle: true when testing bundle-structured policy directories. Use timeout to raise the per-test limit beyond OPA's default 5s. Note: enabling coverage or threshold switches OPA to coverage-report output mode -- per-test counts are unavailable but coverage and coveragePct fields are populated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsYesTest directories or files. `opa test` looks for `*_test.rego` siblings of source files.
verboseNoEmit per-test pass/fail details.
coverageNoInclude per-line coverage data. Switches output to coverage-report mode: test record counts are not available, but `coverage` and `coveragePct` fields are populated.
runPatternNoRun only tests whose names match this regular expression (passed as `--run`).
thresholdNoMinimum coverage percentage required (0–100). Returns COVERAGE_BELOW_THRESHOLD when actual coverage falls below this value. Implicitly enables coverage-report output mode.
varValuesNoInclude local variable bindings in trace output (`--var-values`). When a table-driven test using `every tc in cases { ... }` fails, the trace shows which `tc` triggered the failure. Has no effect unless `verbose: true` is also set (OPA only emits trace entries in verbose mode).
ignorePatternsNoGlob patterns for files to exclude from the test run (`--ignore <pattern>`). Pass one pattern per array element. Useful for excluding generated or fixture files that contain no tests (e.g. `["*_generated.rego", "fixtures/**"]`).
bundleNoLoad paths as OPA bundle roots (`--bundle`). Required when testing policies structured as bundles with a `manifest.json` at the root. Not needed for plain policy directories.
countNoNumber of times to repeat each test (`--count N`). Default is 1. Useful for measuring repeatability or catching flaky tests under load.
timeoutNoPer-test timeout as a Go duration string, e.g. `"30s"` or `"2m"` (`--timeout`). OPA's default is 5s. Increase for tests that load large policy sets or call slow built-ins.
explainNoAdd a query-explanation trace to test records (`--explain`). `fails` traces only failing tests, `full` traces everything, `notes` surfaces `trace()` notes, `debug` is most verbose. Populates each record's `trace` field; pair with `verbose: true` for the human-readable trace output too.
v1CompatibleNoOpt in to OPA v1.0-compatible behaviors (`--v1-compatible`).
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=true, destructive=false, idempotent=true. The description adds behavioral context: coverage/threshold switch to coverage-report mode affecting per-test counts, threshold returns COVERAGE_BELOW_THRESHOLD, varValues only works with verbose, timeout raises per-test limit, bundle required for structured directories. This is transparent but could mention lack of side effects more explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately long for the tool's complexity (12 parameters). It is front-loaded with a summary of the tool's function and return format, then systematically covers each parameter. While every sentence adds value, some minor redundancy could be trimmed, but overall it is well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (12 parameters, no output schema), the description is comprehensive. It covers all parameters, explains outputs (aggregate counts plus per-test records, coverage fields in coverage mode), and provides behavioral interactions. It is complete enough for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning beyond schema descriptions. It explains interactions (coverage disables per-test counts, varValues needs verbose), provides context (essential for debugging table-driven tests), and gives examples (ignorePatterns usage). This greatly helps an agent understand parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs Rego unit tests with `opa test`. It specifies the action (run) and resource (Rego tests). Among siblings like rego_bench, rego_eval, and rego_test_multiroot, the description makes it distinct by focusing on unit tests with `opa test` and detailed parameter guidance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance for when to use each parameter (e.g., use `runPattern` to filter, `threshold` for minimum coverage, `varValues` with `verbose` for debugging). It explains behavioral interactions like coverage mode trade-offs. However, it does not explicitly differentiate from siblings like `rego_test_multiroot`, missing some alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OrygnsCode/opa-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server