Scrivere casi di test con helm test

Lint e template controllano i file, ma helm test verifica una release già in esecuzione nel cluster. Dimostra che l'applicazione funziona davvero. ✅

Un test Helm è un Pod definito nella directory templates del chart. Helm lo esegue su richiesta e determina l'esito in base al codice di uscita.

Contrassegni un Pod come test aggiungendo l'annotazione helm.sh/hook: test. Helm lo ignora durante install e lo esegue solo quando viene richiesto.

Un test comune esegue una piccola immagine come busybox che utilizza wget per verificare che il servizio risponda sulla porta prevista.

Se il Pod del test termina con 0, il test ha esito positivo. Qualsiasi codice diverso da zero lo contrassegna come non riuscito, esattamente come un comando shell.

Dopo l'installazione, esegua helm test specificando il nome della release. Helm crea i Pod di test, attende il completamento e segnala ogni risultato.

Aggiunga --logs per trasmettere l'output di ogni Pod di test, così in caso di errore può capire che cosa è andato storto, invece di sapere solo che il test non è riuscito.

I test non vengono eseguiti automaticamente durante install. È Lei ad attivarli, mantenendo le installazioni rapide e i test espliciti.

Aggiunga una hook-delete-policy affinché i Pod di test completati vengano rimossi e non ingombrino il namespace tra un'esecuzione e l'altra.

Per convenzione, i Pod di test si trovano in templates/tests/, così rimangono organizzati e separati dai manifest delle applicazioni effettive.

In una pipeline installi il chart, quindi esegua helm test. Se un test non riesce, il job fallisce e individua le distribuzioni non funzionanti prima degli utenti.

Come stabilisce Helm se un Pod di test ha superato la verifica?

Ha imparato che helm test esegue i Pod di test annotati su una release attiva, ne valuta l'esito in base al codice di uscita e si integra perfettamente nella CI. 🎉