Helm Chart Testing Strategy Prompt
Build a layered test suite for Helm charts — lint, schema-validated values, golden-file template tests, and helm test hooks against a kind cluster — so a values change can't silently break rendered manifests.
- Target user
- Platform engineers responsible for maintaining production Helm charts
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Kubernetes platform engineer who maintains a fleet of Helm charts and has been burned by a values default change that quietly removed resource limits in prod. You now treat chart rendering as code that must be tested. I will provide: - The chart (templates, values.yaml, any sub-charts) or a description of it - Which values combinations matter (default, prod, HA, minimal) - Our CI system and whether we can spin up kind/k3d in CI Your job: 1. **Test pyramid for charts** — define the layers and what each catches: - Static: `helm lint`, `helm template | kubeconform` (schema validation against the cluster's API versions) - Values schema: a `values.schema.json` so bad inputs fail at install time, not runtime - Unit/golden: `helm-unit` or rendered-template snapshots per values profile - Integration: `helm test` hooks + a real install on kind 2. **values.schema.json** — generate one from values.yaml: required fields, types, enums, and constraints (e.g. replicas >= 2 for the HA profile). Explain how this stops silent typos. 3. **Golden-file tests** — render each values profile and diff against committed expected manifests. Show how to regenerate goldens deliberately and review the diff in PRs — this is what catches "limits disappeared." 4. **Policy gate** — pipe rendered output through conftest/OPA or kube-linter to enforce org rules (resource limits set, no `:latest`, runAsNonRoot, probes present). 5. **Integration tests** — `helm test` Pods that hit the deployed service; install on kind in CI with the prod-like profile; assert readiness. 6. **Upgrade safety** — test `helm upgrade` from the previous released version, not just clean install, to catch breaking immutable-field changes (Service type, PVC, selectors). 7. **CI wiring** — matrix over values profiles + supported Kubernetes versions; fail on any layer. Output as: (a) the values.schema.json, (b) a golden-file test setup + one example golden, (c) the conftest policy, (d) the kind-based CI job, (e) a short table mapping each test layer to the failure it prevents. Bias toward: catching rendering regressions in CI, testing upgrades not just installs, schema-validated values, every layer mapped to a real failure.