Wprowadzenie

W poprzednim wpisie pokazałem, w jaki sposób tworzyć automatyczne testy API w karate. Uruchamiałem je lokalnie z poziomu Visual Studio oraz wiersza poleceń. Ale największą ich zaletą jest automatyczne uruchamianie podczas procesu CI/CD. Zobacz, w jaki sposób to zrobić na przykładzie Azure DevOps.

Karate i Azure DevOps

Automatyczne wykonywanie testów karate w Azure DevOps nie jest skomplikowane. Jest nawet prostsze niż w przypadku wykonywania testów Postmana. Nie potrzebujemy instalować dodatków do Azure DevOps, aby uruchamiać testy, tak jak to było w przypadku Postmana. Ale kroki i idea są bardzo podobne.

W definicji samego pipeline potrzebujemy tylko skopiować folder Tests z głównego folderu repozytorium, w którym znajduje się aplikacja karate z testami. Krok ten wygląda tak:

Całą definicję pipeline z testowego przykładu możesz znaleźć w repozytorium – https://github.com/danielplawgo/KarateTests/blob/main/azure-pipelines.yml

W tym momencie możemy przejść do definicji release.

Release

Większość rzeczy będzie działa się tutaj. Podobnie jak w przypadku testów Postmana i tutaj będziemy je uruchamiali po wdrożeniu nowej wersji aplikacji.

Na początku musimy dodać zmienne (variables) do definicji release. W nim będziemy określali adres aplikacji i inne rzeczy potrzebne do wykonywania testów. Wartości te później przed uruchomieniem testów nadpiszą ustawienia, które znajdują się w pliku environment-config.json.

W moim przykładzie konfiguracja zmiennych wygląda tak:

Przykładowy release będzie składał się z czterech kroków:

Będą to kolejno:

• Wrzucenie nowej wersji aplikacji – tutaj do App Service
• Podmienienie wartości w environment-config.json na podstawie zmiennych, które przed chwilą dodaliśmy
• Wykonanie skryptu run.cmd – o którym było w poprzednim wpisie
• Publikacja wyników wykonania testów do Azure DevOps

W realnej aplikacji kroków w release możesz mieć więcej. Na przykład wykonywanie migracji Entity Framework Core.

Zobacz, jak skonfigurować poszczególne kroki.

Transformacja environment-config.json

Konfigurację pierwszego kroku pominę. Jest ona mocno zależna od tego, gdzie wdrażamy aplikację. A do tego nie jest to właściwy temat tego wpisu.

W drugim kroku wykonujemy transformację pliku environment-config.json. Dla przypomnienia w pliku tym trzymamy wszystkie zmienne wartości testów, takie jak adres aplikacji, czyli login i hasło w przykładzie. Wartości te są później specyficzne dla każdego środowiska, dla którego chcemy uruchamiać testy i są podmieniane właśnie w tym kroku.

Konfiguracja kroku wygląda tak:

Kolejno określamy:

• nazwę kroku (punkt 1)
• folder, w którym znajduje się nasz plik (punkt 2)
• format pliku – tutaj json (punkt 3)
• nazwę pliku – environment-config.json (punkt 4)

Po jego wykonaniu wartości ze zmiennych nadpiszą wartości w pliku environment-config.json

Wykonanie testów

Kolejny krok to faktyczne wykonanie testów. Tutaj korzystam z pliku run.cmd. Pobiera on wykonywany plik karate i później uruchamia testy. Dla przypomnienia jego zawartość to:

W tym kroku wykonujemy tylko ten skrypt. Komputery, na których są wykonywane release’y, mają zainstalowane środowisko uruchomieniowe javy, więc, co fajne, nie musimy tutaj nic instalować i konfigurować.

Konfiguracja kroku wygląda tak:

Ustawiamy kolejno:

• nazwę kroku (punkt 1)
• skrypt, który ma być wykonany – tutaj po prostu run (punkt 2)
• folder, gdzie znajduje się skrypt (punkt 3)
• zaznaczamy „Continue on error” (punkt 4)

Krok ten wykona testy i ich wynik zapisze do folderu target w różnych formatach, jak to pokazałem wcześniej. Pozostaje nam teraz tylko opublikować wyniki.

Istotne jest tutaj zaznaczenie flagi „Continue on error”. Karate, w momencie, gdy jakiś test nie przechodzi, zwraca do systemu code 1. Azure DevOps traktuje to jako błędne wykonanie kroku i przerywa wykonywanie release. Co spowoduje, że nie zostanie opublikowana informacja o wyniku testów. Ustawienie flagi spowoduje, że release przejdzie do kolejnego kroku, a w nim następnie dodamy warunek, który spowoduje błędne wykonanie release, gdy co najmniej jeden test wykona się z błędem.

Publikacja wyników

Ostatnim krokiem jest opublikowanie wyników. Tutaj wykorzystamy format jUnit oraz pliki xml, które generuje karate.

Konfiguracja kroku:

Kolejno ustawiłem:

• nazwę kroku (punkt 1)
• format wyników – jUnit (punkt 2)
• wzorzec dla plików z wynikami – **/*.xml (punkt 3)
• zaznaczamy „Fail if there are test failures” (punkt 4)

Ostatni czwarty punkt powoduje właśnie zatrzymanie release z błędem w momencie, gdy jeden z testów wykonał się niepoprawnie.

W tym momencie możemy cieszyć się automatycznym wykonywaniem testów karate w Azure DevOps.

Przykład

Rozszerzyłem przykład z wcześniejszego wpisu o karate. Całość możesz znaleźć na githubie – https://github.com/danielplawgo/KarateTests

Podsumowanie

Skonfigurowanie automatycznego uruchamianie testów karate w Azure DevOps nie wymaga dużej ilości pracy. Można to zrobić dosłownie w kilka minut. Osobiście jestem gorącym zwolennikiem wszelkich automatycznych testów, który wyłapią szybciej problemy w aplikacji.