Zautomatyzuj swoje testy API za pomocą Jenkins, Postman i Newman

trochę tła

w dzisiejszych czasach rurociągi CI są koniecznością w naszej codziennej pracy programistycznej, pomagając nam skrócić cykle dostaw i wprowadzić oprogramowanie wyższej jakości.

jako programista zaplecza, interfejsy API stały się kamieniem węgielnym w większości moich aplikacji, więc testowanie ich stało się koniecznością.

etap testowania API w naszym rurociągu CI daje nam pewność co do jakości produktu i ostrzega nas, jeśli coś się zepsuło.

Listonosz

Listonosz to świetne narzędzie, które pomaga programistom na każdym etapie naszego cyklu życia API. Ma świetną dokumentację i coraz większą społeczność programistów, którzy go używają, więc łatwo jest znaleźć posty wyjaśniające fajne porady i sztuczki.

Kolekcje

Listonosz ułatwia uporządkowanie różnych naszych próśb w Kolekcje. Osobiście tworzę kolekcję do każdego projektu, który chcę przetestować. Następnie, wewnątrz kolekcji, tworzę folder dla każdego podmiotu w projekcie, starając się pokryć każdy punkt końcowy w API.

środowiska

Listonosz pozwala nam tworzyć różne środowiska do uruchamiania naszych żądań. Podając prawdziwy przykład, powiedziałbym, że pracuję na trzech różnych środowiskach: moim środowisku lokalnym, środowisku tymczasowym i środowisku produkcyjnym, więc tworzę trzy różne środowiska ze zmiennymi, które reprezentują zmieniające się dane między środowiskami (jak ścieżka bazowa dla żądań API). W ten sposób mogę zdefiniować pojedyncze żądanie, ale łatwo kierować je do moich trzech różnych środowisk. Pomyśl o tym, jak łatwo byłoby zmienić lub dodać nowe środowisko!

testowanie żądań

jedną z największych cech Postman jest to, że pozwala na kodowanie testów, które są uruchamiane za każdym razem, gdy żądanie jest uruchamiane. Są one napisane w JS i mają fajny zestaw asercji do sprawdzania takich rzeczy jak kod odpowiedzi, ciało odpowiedzi o nagłówki odpowiedzi.

Super! Po napisaniu pakietu testowego obejmującego nasze API, używamy Collection Runner, wbudowanego narzędzia dostarczanego przez Postmana, aby uruchomić każde żądanie kolekcji i wydrukować raport z wyników testów.

Bonus: Czasami chcemy uruchomić nasze żądania w określonej kolejności i zgadnij co? Listonosz nam na to pozwala! Sprawdź to w kwestii przepływów pracy w budownictwie

co mamy do tej pory?

w tym momencie stworzyliśmy kolekcję listonoszy z mnóstwem żądań, które mogą kierować nasze API we wszystkich naszych środowiskach. Poza tym, każde żądanie ma kilka testów, aby sprawdzić, czy działa prawidłowo. Co za czas, by żyć!

Newman

pamiętasz kolekcję Runner, o której wspomniałem wcześniej? Może uruchomić każde żądanie w naszej kolekcji za pomocą jednego kliknięcia. Ale co z narzędziem wiersza poleceń, aby zrobić to samo? Newman to robi. Newman to program do uruchamiania i testowania kolekcji listonoszy, który pozwala na uruchamianie i testowanie kolekcji listonoszy bezpośrednio z wiersza poleceń i łatwą integrację z serwerami CI, co czyni go doskonałym narzędziem do naszego celu: zautomatyzować nasz test API za pomocą Jenkinsa.

Uruchom kolekcję

aby uruchomić kolekcję z Newmanem, najpierw musimy wyeksportować ją z listonosza. Ponieważ mamy pewne zmienne w niektórych naszych żądaniach, musimy również wyeksportować odpowiednie środowisko. Gdy mamy oba pliki, jesteśmy w stanie uruchomić kolekcję z:

$ newman run our.postman_collection.json -e our.postman_environment.json

i zobaczymy raport z uruchomienia kolekcji, podobny do innych frameworków testowych.

formatowanie wyjścia

raport można formatować na różne sposoby. Aby to osiągnąć, Newman zapewnia zestaw reporterów obsługujących różne formaty wyjściowe, takie jak JSON, XUNIT lub HTML. Poza tym możesz stworzyć własnego reportera, aby sformatować raport w dowolnym formacie.

Jenkins

fajne, zdefiniowaliśmy nasz pakiet testów API z listonoszem i jesteśmy w stanie uruchomić go z wiersza poleceń i uzyskać ładny raport z wyników do tej pory z Newmanem. Ale teraz chcemy włączyć naszą niesamowitą nową umiejętność do naszego rurociągu CI.

Zastrzeżenie: używamy Jenkinsa jako serwera automatyzacji do budowania naszych potoków CI / CD i uruchamiamy nasz potok CI w kontenerze Docker, który ma zainstalowane wszystkie niezbędne narzędzia (takie jak Newman).

mieszanie rzeczy

zasadniczo będziemy potrzebować trzech plików, aby dołączyć nasz Test API do potoku CI:

• Jenkinsfile, który definiuje nasz rurociąg
• Postman Collection, który definiuje nasz zestaw żądań i testów
• środowisko Postman, które definiuje zmienne środowiska docelowego

wszystkie z nich umieszczamy w repozytorium projektu, dzięki czemu możemy korzystać z kontroli wersji nad nimi i śledzić ich zmiany.

dość gadania, zakodujmy!

musimy utworzyć nowy etap w naszym potoku, aby uruchomić Test API. Zwykle umieszczamy go po testach jednostkowych i integracyjnych, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami przed testowaniem interfejsu.

pipeline { ... stage('Test API Rest') { steps { sh 'newman run tests/Newman/our.postman_collection.json -e tests/Newman/env/test.postman_environment.json -r junit,html --reporter-junit-export var/reports/newman/junit/newman.xml --reporter-html-export var/reports/newman/html/index.html' publishHTML() } } ...}

jak widać, wywołujemy polecenie Uruchom Newmana, dostarczając naszej kolekcji plik środowiska testowego jako parametry. Poza tym informujemy również, których reporterów chcemy użyć (JUNIT, HTML) i gdzie będą przechowywane dane wyjściowe.

jako bonus używamy wtyczki HTML PUblisher Jenkins, aby połączyć raport HTML z kompilacją.

mam nadzieję, że podobała ci się ta podróż tak samo, jak ja ją pisałem i jak zawsze opinie będą mile widziane!