What does `helm test` do when you run it against an installed release?

## What the command actually is `helm test RELEASE_NAME` is Helm's only command that runs *your* code against a release that is already live. Everything else Helm offers in the checking family works on chart source: it renders templates, validates values, or diffs YAML. `helm test` does none of that. It takes the name of an installed release, finds the resources in it that are marked as test hooks, creates them in the cluster, and tells you whether they succeeded. ## What has to exist first Two things. A release of that name must exist in the namespace you point at (`-n`, or whatever `HELM_NAMESPACE` resolves to) - if there is no release, the command errors out before it touches the cluster. And the chart that release was installed from must contain at least one manifest annotated `helm.sh/hook: test`. If the chart has none, `helm test` succeeds trivially and has proved nothing at all, which is a real trap: a green test on a chart with no tests looks identical in CI to a green test that actually connected to something. The scaffolding `helm create` emits includes a connection test under `templates/tests/` - a small Pod that fetches the release's own Service. That file is a starting point, not a smoke test worth trusting; most teams replace its body with a request that exercises a real endpoint. ## The lifecycle of a run Helm creates the test resources, then waits. The unit of judgement is the Pod: every container in it must terminate, and terminate with exit status 0, for the Pod to reach the `Succeeded` phase. That is why a test Pod must be written as a **command that ends** - a request, an assertion, an exit - rather than as a server. A Pod that keeps running is not passing slowly; it is not passing at all, and it will burn the whole wait budget before Helm gives up. When every test Pod has finished, Helm reports each one as passed or failed and sets its own exit status accordingly. Non-zero on failure is what makes the command usable as a pipeline step. `--logs` prints the test Pods' container output after the run completes, which is normally the fastest way to see what a failing assertion actually said. `--filter name=<pod-name>` narrows a multi-test chart to a single test while you iterate. ## What it does *not* touch `helm test` does not create a new revision. The release's revision number, its stored manifest and its stored values are all unchanged by a test run, which is why running it repeatedly is cheap and why a passing test is not itself recorded as part of the deployment history. It is also not part of `helm install` or `helm upgrade`: the install finishes, the release is already serving, and the test runs afterwards as a separate command. If you want the test to gate a rollout, your pipeline has to run it and act on the exit code itself. It is also not a substitute for the pre-merge checks a chart needs. Rendering the templates, validating a values file against a schema and asserting on the produced YAML all happen before anything reaches a cluster and catch a different class of defect - a typo in a template, an unset required value. `helm test` catches the class those cannot see: the chart rendered fine, the objects were accepted by the API server, and the thing still does not work because a Service selector matches nothing, a Secret key is spelled differently from the one the app reads, or a dependency is unreachable from that namespace. ## Why the distinction matters in an interview Candidates routinely describe `helm test` as "validating the chart". It validates nothing about the chart. It runs a Pod in a cluster against a running release and reports whether that Pod exited cleanly. Everything the test proves comes from what you wrote inside it, and everything it cannot prove comes from the fact that it is one process, run once, from inside one namespace.