Karate – uruchamianie testów w Azure DevOps

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:

- task: PublishPipelineArtifact@1
inputs:
targetPath: '$(Build.Repository.LocalPath)/Tests'
artifact: 'Tests'
view raw pipelines.yml hosted with ❤ by GitHub

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.

Darmowy kurs Visual Studio

Pracując z setkami programistów, zauważyłem, że większość osób nie pracuje efektywnie w Visual Studio. W skrajnych przypadkach korzystali z kopiowania z wykorzystaniem menu Edit. Wiem, że to dziwne, ale naprawdę niektórzy tak pracują. Dlatego postanowiłem stworzyć kurs Visual Studio – aby pomóc koleżankom i kolegom w efektywniejszej pracy.

Przygotowałem 30 lekcji e-mail, w których pokażę Ci, w jaki sposób pracować efektywniej i szybciej w Visual Studio. Poznasz dodatki, bez których nie wyobrażam sobie pracy w tym IDE.

Po więcej informacji zapraszam na dedykowaną stronę kursu: Darmowy Kurs Visual Studio.

Quiz C#

Ostatnio przygotowałem również quiz C#, w którym możesz sprawdzić swoją wiedzę. Podejmiesz wyzwanie?

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:

Konfiguracja zmiennych w Azure DevOps

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

Taski w release

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:

Konfiguracja kroku file transform

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:

curl -L https://github.com/intuit/karate/releases/download/v0.9.6/karate-0.9.6.jar --output karate.jar
java -jar karate.jar -t ~@ignore src
view raw run.cmd hosted with ❤ by GitHub

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:

Konfiguracja publikacji wyników testu

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.

1 thought on “Karate – uruchamianie testów w Azure DevOps

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *