opa-testing
This skill should be used when the user asks to "test opa", "opa test", "test rego", "write rego tests", "policy coverage", "conftest verify", "mock opa", or mentions `_test.rego` files. Provides OPA testing framework guidance including unit tests, mocking, coverage, and Conftest patterns.
What this skill does
# OPA Testing
Comprehensive guide for testing OPA/Rego policies using `opa test`, Conftest, and related tooling.
**REQUIRED: Every test suite MUST include all three categories:**
1. **Positive tests** -- valid input that should produce zero violations
2. **Negative tests** -- invalid input that should trigger specific violations
3. **Edge case tests** -- empty input, missing fields, null values, boundary conditions
Edge cases are NOT optional "nice-to-have" tests. They catch the most dangerous bugs: policies that silently fail to enforce when fields are missing. A policy without edge case tests is an untested policy.
**REQUIRED: Verify violation messages, not just counts.** Tests that only assert `count(result) > 0` prove a violation exists but NOT that the correct rule fired. Always verify message content:
```rego
# WRONG: only checks count
test_deny_privileged if {
result := violation with input as bad_pod
count(result) > 0
}
# CORRECT: verifies the right violation fired
test_deny_privileged if {
result := violation with input as bad_pod
count(result) > 0
some msg in result
contains(msg, "privileged")
}
```
## Testing Framework Overview
| Tool | Purpose | When to Use |
|------|---------|-------------|
| `opa test` | Unit test Rego policies | Always - primary testing mechanism |
| `conftest verify` | Test Conftest policies | When using Conftest for structured config |
| `opa eval` | Ad-hoc evaluation | Debugging, exploration |
| `opa bench` | Performance testing | Optimizing hot-path policies |
---
## Test File Conventions
Test files use `_test.rego` suffix and share the same package as the policy under test:
```
policies/
├── kubernetes/
│ ├── pod_security.rego # Policy
│ └── pod_security_test.rego # Tests
├── terraform/
│ ├── s3_encryption.rego
│ └── s3_encryption_test.rego
└── lib/
├── helpers.rego
└── helpers_test.rego
```
---
## Writing Tests
### Basic Test Structure
```rego
package kubernetes.pod_security_test
import rego.v1
import data.kubernetes.pod_security
# Test rule prefix: test_
test_deny_privileged_container if {
result := pod_security.violation with input as {
"review": {"object": {"spec": {"containers": [
{"name": "nginx", "securityContext": {"privileged": true}}
]}}}
}
count(result) > 0
}
test_allow_non_privileged_container if {
result := pod_security.violation with input as {
"review": {"object": {"spec": {"containers": [
{"name": "nginx", "securityContext": {"privileged": false}}
]}}}
}
count(result) == 0
}
```
### Test Naming Convention
| Prefix | Meaning |
|--------|---------|
| `test_` | Active test (PASS/FAIL) |
| `todo_` | Skipped test (SKIPPED) |
Name tests descriptively: `test_<rule>_<scenario>_<expected_outcome>`
```rego
test_deny_when_container_privileged if { ... }
test_allow_when_securitycontext_drop_all if { ... }
test_deny_when_no_resource_limits_set if { ... }
```
---
## Mocking with `with`
The `with` keyword replaces values during evaluation:
### Mock Input
```rego
test_allow_admin if {
pod_security.allow with input as {"user": {"role": "admin"}}
}
```
### Mock Data
```rego
test_with_external_data if {
result := authz.allow with input as {"user": "alice"}
with data.roles as {"alice": ["admin"]}
}
```
### Mock Functions
```rego
test_with_mocked_time if {
result := policy.is_expired with time.now_ns as 1672531200000000000
}
test_with_mocked_http if {
mock_response := {"status_code": 200, "body": {"allowed": true}}
result := policy.check_external with http.send as mock_response
}
```
### Mock Built-in Rules
```rego
test_with_mocked_rule if {
policy.main_decision with data.policy.helper_rule as true
}
```
---
## Running Tests
### Basic Commands
```bash
# Run all tests
opa test . -v
# Run tests in specific directory
opa test ./policies/ -v
# Run tests matching regex
opa test . -v --run "test_deny.*privileged"
# JSON output for CI
opa test . --format=json
# With coverage
opa test . -v --coverage
# With coverage threshold (exit non-zero if below)
opa test . --coverage --threshold 80
# Show variable values on failure
opa test . -v --var-values
# Benchmark tests
opa test . --bench --benchmem
```
### Test Output Format
```
PASS: 12/15
FAIL: 2/15
SKIPPED: 1/15
data.kubernetes.pod_security_test.test_deny_privileged: PASS (1.234ms)
data.kubernetes.pod_security_test.test_deny_no_limits: FAIL (0.567ms)
rule "test_deny_no_limits" body was undefined
data.kubernetes.pod_security_test.todo_future_feature: SKIPPED
```
---
## Coverage Analysis
```bash
# Generate coverage report
opa test . --coverage --format=json > coverage.json
# Threshold enforcement
opa test . --coverage --threshold 80
```
Coverage tracks which lines of policy code are exercised by tests. Target:
- **80%+** for critical security policies (deny rules, admission control)
- **70%+** for standard policies
- **60%+** for helper libraries
---
## Test Organization Patterns (All Three Categories Required)
### Positive/Negative/Edge Case Structure
```rego
# === Positive Tests (policy should allow) ===
test_allow_valid_pod if {
count(violation) == 0 with input as valid_pod
}
# === Negative Tests (policy should deny -- ALWAYS verify message content) ===
test_deny_privileged if {
result := violation with input as privileged_pod
count(result) > 0
some msg in result
contains(msg, "privileged") # Verify the RIGHT rule fired
}
# === Edge Cases (REQUIRED -- catch silent enforcement failures) ===
test_edge_empty_containers if {
count(violation) == 0 with input as {"spec": {"containers": []}}
}
test_edge_missing_security_context if {
# This catches the most dangerous bug: policy silently not firing on missing fields
result := violation with input as {"spec": {"containers": [{"name": "test"}]}}
count(result) > 0 # Container with NO securityContext should still trigger deny
}
test_edge_empty_input if {
count(violation) == 0 with input as {}
}
test_edge_null_field if {
result := violation with input as {"spec": {"containers": [{"name": "test", "securityContext": null}]}}
count(result) > 0
}
# === Test Fixtures ===
valid_pod := {"spec": {"containers": [
{"name": "app", "securityContext": {"runAsNonRoot": true, "privileged": false}}
]}}
privileged_pod := {"spec": {"containers": [
{"name": "app", "securityContext": {"privileged": true}}
]}}
```
### Parameterized Tests
```rego
# Multiple test cases via separate rules
test_deny_privileged_single if { _test_deny_privileged(1) }
test_deny_privileged_multiple if { _test_deny_privileged(3) }
_test_deny_privileged(n) if {
containers := [c |
some i in numbers.range(0, n - 1)
c := {"name": sprintf("c%d", [i]), "securityContext": {"privileged": true}}
]
result := violation with input as {"spec": {"containers": containers}}
count(result) == n
}
```
---
## Conftest Testing
For testing structured configuration files (Terraform, K8s YAML, Docker):
```bash
# Test Terraform plan
terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json
conftest test tfplan.json -p policy/
# Test Kubernetes manifests
conftest test deployment.yaml -p policy/
# Test Dockerfiles
conftest test Dockerfile -p policy/
# Verify policy tests
conftest verify -p policy/
```
### Conftest Test File
```rego
package main_test
import rego.v1
import data.main
test_deny_no_encryption if {
result := main.deny with input as {
"resource_changes": [{"type": "aws_s3_bucket", "change": {"after": {"server_side_encryption_configuration": null}}}]
}
count(result) > 0
}
```
---
## CI/CD Integration
```yaml
# GitHub Actions example
- name: Run OPA Tests
run: |
opa test ./policies/ -v --coverage --threshold 80 --format=json > test-results.json
- name: Run Conftest
run: |
conftest test tfplan.json -p policy/Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.