Helm / Templates / Testing

Helm Library Charts and Helm Unit Test

How I think about reusable Helm templates, library charts, and testing rendered Kubernetes manifests before shipping them.

What is Helm

If Kubernetes is the operating system, Helm is close to the package manager. It packages Kubernetes resources into charts and lets us install, upgrade, configure, and roll back applications with a consistent interface.

Helm becomes very useful when many services share the same deployment pattern: Deployment, Service, ConfigMap, Secret, PDB, HPA, ingress, and common labels.

Chart structure

A Helm chart is a directory of templates and default values. The templates produce Kubernetes YAML. The values file controls environment-specific configuration.

my-service/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
    configmap.yaml
    _helpers.tpl

The risk is duplication. If every service owns its own copy of the same template logic, every bug fix becomes repeated work.

Library chart

A library chart contains reusable named templates. Application charts can include those templates and pass their values into a shared implementation.

{{- define "util.app" -}}
{{ include "util.configMap" . }}
---
{{ include "util.secret" . }}
---
{{ include "util.pdb" . }}
---
{{ include "util.serviceAccount" . }}
---
{{ include "util.deployment" . }}
---
{{ include "util.service" . }}
{{- end -}}

This keeps common Kubernetes building blocks consistent while still letting each service provide its own values.

Helm unit tests

Template reuse helps, but it also increases blast radius. A broken library template can affect many services. That is why rendered manifest tests matter.

suite: deployment
templates:
  - templates/deployment.yaml
tests:
  - it: sets the expected image
    set:
      image.repository: nginx
      image.tag: "1.25"
    asserts:
      - equal:
          path: spec.template.spec.containers[0].image
          value: nginx:1.25

The goal is not to test Kubernetes itself. The goal is to test the chart contract: labels, selectors, ports, resources, probes, env vars, and conditional resources.

Notes

  • Library charts are good when service manifests are truly similar.
  • Do not hide every detail behind templates; keep service values readable.
  • Test the rendered output, not just template syntax.
  • Keep helper names stable because many charts can depend on them.
A Helm library chart is useful only when it makes service charts easier to reason about, not when it hides all Kubernetes details.