Linting, testing & schemas
helm lint, test, values schema.
Charts are code that renders cluster manifests, so they deserve validation before release. helm lint checks a chart for structural problems and best-practice issues. helm template renders the chart locally (no cluster) so you can eyeball or diff the output. And a values.schema.json validates user-supplied values against a JSON Schema at install time, rejecting a bad type or a missing required field with a clear error instead of a broken manifest.
$ helm lint ./payments-api==> Linting ./payments-api1 chart(s) linted, 0 chart(s) failed$ helm template payments ./payments-api -f prod-values.yaml | kubeconform -strict# render, then validate the output against the Kubernetes schemas
{"$schema": "https://json-schema.org/draft-07/schema#","type": "object","required": ["image"],"properties": {"replicaCount": { "type": "integer", "minimum": 1 },"image": { "type": "object", "required": ["repository", "tag"] }}}
Chart tests
Helm also supports release tests: templates annotated helm.sh/hook: test (usually a Job that curls the service or checks a connection), run on demand with helm test <release>. They verify a release actually works after install/upgrade, not just that it rendered. Combined with lint, schema validation, and rendered-output checks in CI, you catch the vast majority of chart problems before they reach a cluster.
$ helm install payments ./payments-api -n prod$ helm test payments -n prodPhase: Succeeded # the test Job connected to the service successfully