Pisanie przypadków testowych helm test

Lint i template sprawdzają pliki, ale helm test sprawdza wydanie, które już działa w klastrze. Pozwala potwierdzić, że aplikacja rzeczywiście działa. ✅

Test Helm to obiekt Pod zdefiniowany w katalogu templates chartu. Helm uruchamia go na żądanie, a o powodzeniu decyduje kod wyjścia.

Obiekt Pod oznacza się jako test, dodając adnotację helm.sh/hook: test. Helm pomija go podczas install i uruchamia dopiero na żądanie.

Typowy test uruchamia niewielki obraz, taki jak busybox, który za pomocą wget potwierdza, że usługa odpowiada na swoim porcie.

Jeśli obiekt Pod testu kończy działanie z kodem 0, test przechodzi pomyślnie. Każdy kod różny od zera oznacza niepowodzenie, dokładnie tak jak w przypadku polecenia powłoki.

Po instalacji należy uruchomić helm test, podając nazwę wydania. Helm tworzy testowe obiekty Pod, czeka na ich zakończenie i wyświetla wynik każdego testu.

Dodanie opcji --logs powoduje strumieniowe wyświetlanie danych wyjściowych każdego testowego obiektu Pod, dzięki czemu w razie niepowodzenia wiadomo, co poszło nie tak, a nie tylko że test się nie powiódł.

Testy nie są uruchamiane automatycznie podczas install. Uruchamiają je Państwo samodzielnie, dzięki czemu instalacje pozostają szybkie, a testy są jawne.

Należy dodać hook-delete-policy, aby zakończone testowe obiekty Pod były usuwane i nie zaśmiecały przestrzeni nazw pomiędzy kolejnymi uruchomieniami.

Zgodnie z konwencją testowe obiekty Pod znajdują się w katalogu templates/tests/, dzięki czemu są uporządkowane i oddzielone od manifestów właściwych obciążeń.

W potoku najpierw instaluje się chart, a następnie uruchamia helm test. Nieudany test powoduje niepowodzenie zadania, wykrywając błędne wdrożenia, zanim zrobią to użytkownicy.

Jak Helm ustala, czy testowy obiekt Pod zakończył się powodzeniem?

Dowiedzieli się Państwo, że helm test uruchamia opatrzone adnotacją testowe obiekty Pod przeciwko działającemu wydaniu, ocenia je na podstawie kodu wyjścia i dobrze pasuje do CI. 🎉