Testing Charts

Layers of chart testing

Test charts the way you test code, from cheap to expensive. helm lint catches structural problems and template errors. Rendering plus Kubernetes schema validation, for example helm template ... | kubeconform -strict, catches misspelled fields and wrong API versions without a cluster. Unit tests with the community helm-unittest plugin assert on rendered output ("when ingress.enabled is true, an Ingress with host X exists"), which protects tricky conditionals from regressions. Install tests with the chart-testing tool (ct lint and ct install) install changed charts into a throwaway cluster, often kind, run helm test, and check that upgrades from the previous version work. Run a value matrix: defaults, production-like values and each optional feature switched on.

The chart testing ladder

Each step catches more problems but costs more time.

A helm-unittest test file

Lives in tests/ inside the chart and runs with helm unittest ./charts/shop-api.

suite: ingress
templates:
  - templates/ingress.yaml
tests:
  - it: is not rendered by default
    asserts:
      - hasDocuments:
          count: 0

  - it: renders one rule per host
    set:
      ingress.enabled: true
      ingress.className: nginx
      ingress.hosts:
        - host: shop.example.com
        - host: api.example.com
    asserts:
      - isKind:
          of: Ingress
      - equal:
          path: spec.rules[1].host
          value: api.example.com

Test the upgrade, not just the install

Many chart bugs only appear when upgrading an existing release: renamed resources, changed selectors, new required values. chart-testing can install the previous version and upgrade to the new one; use that in CI.

Quick check: Which approach validates rendered manifests against Kubernetes schemas without a cluster?

• helm rollback
• helm status
• helm template piped to kubeconform
• kubectl get pods