introduction contract testing with examples
Ten samouczek dotyczący testowania kontraktów Pakt wyjaśnia, czym jest testowanie kontraktów kierowane przez konsumenta, jak to działa i dlaczego warto go używać w swojej strategii testowania:
Co to jest testowanie kontraktowe?
Testowanie kontraktowe kierowane przez konsumenta jest formą testowania API, która naprawdę umożliwia przesunięcie w lewo. Narzędzie umowy, którego używamy, to Pact.io , o czym dowiemy się w dalszej części tej serii samouczków.
Testowanie kontraktowe to metoda niezależnego sprawdzenia integracji między dwiema aplikacjami w celu przetestowania tego, co zostało przekazane, i sprawdzenia, czy to, co zostanie zwrócone, pasuje do „umowy”.
Testy kontraktowe dobrze pasują do architektury mikrousług, działając w środowisku zwinnym. Dlatego przykłady będą oparte na doświadczeniach, które zdobyliśmy pracując w tym środowisku.
Czego się nauczysz:
- Lista samouczków w tej serii testów kontraktowych
- Testowanie umów kierowane przez klienta
- Testowanie kontraktowe a testowanie integracyjne
- Ciągła integracja
- Wniosek
Lista samouczków w tej serii testów kontraktowych
Samouczek nr 1: Wprowadzenie do testowania kontraktowego z przykładami [Ten samouczek]
Samouczek nr 2: Jak napisać test paktu konsumenckiego w JavaScript
Samouczek nr 3: Jak opublikować umowę paktową z brokerem paktowym
Samouczek nr 4: Zweryfikuj umowę paktową i ciągłe wdrażanie za pomocą interfejsu wiersza polecenia Pact
Testowanie umów kierowane przez klienta
Punktem wyjścia jest dokumentacja API, która stanowi umowę na testy, w tym momencie zespoły programistyczne zwykle biorą dokument API i opracowują go w oparciu o dokument wiki (lub inny format, który znajduje się w twojej organizacji, taki jak dokument Word).
Na przykład, aplikacja internetowa, w której front-end jest tworzony przez Team Krypton, a API jest rozwijane przez Team Thoron. Projekt rozpoczyna się od spotkania inauguracyjnego, podczas którego przedstawiane są wymagania i uzgadniane między zespołami.
Każdy zespół przyjmuje wymagania i zaczyna tworzyć zaległości, udoskonalając historie. Rozwój rozpoczyna się w obu zespołach podążając za historyjkami użytkownika, testy integracyjne pozostawia się na późniejsze sprinty. Ponieważ Team Krypton znajduje dodatkowe wymagania, dotyczące scenariuszy błędów, dokumentacja API jest odpowiednio aktualizowana.
Przypadki testowe są dodawane przez Team Thoron w związku ze zaktualizowanymi scenariuszami na podstawie dokumentacji.
Już widzimy kilka błędów w tym procesie, a na szczęście dodałem jeszcze kilka:
- Zmiany w dokumentach API mogą nie być skutecznie przekazywane.
- Zespół frontendowy blokuje usługę zaplecza i na odwrót.
- Zespół zaplecza tworzy przypadki testowe integracji na podstawie dokumentacji.
- Środowisko integracyjne jest pierwszym testem pełnej integracji.
- Inna wersja API na środowisku integracyjnym a produkcyjna
Testowanie umów z inicjatywy konsumenta ma dwie strony, tj. Konsumenta i dostawcę. W tym miejscu odwraca się tradycyjne myślenie o testowaniu w mikrousługach.
Plik Konsument jest kuratorem scenariuszy, w tym zapytania i oczekiwanej odpowiedzi. To pozwala na śledzenie Prawo łóżka który mówi, że powinieneś być elastyczny w tym, co twój API może zaakceptować, ale konserwatywny w tym, co jest wysyłane. Odnosząc się do wad nie. 1, 3 i 4 zmiany dokumentacji są kierowane przez konsumenta.
Na przykład, w sytuacji, gdy Team Thoron zmienia pole tekstowe, aby nie akceptowało wartości zerowych, testy konsumenckie nie odzwierciedlałyby zmiany i dlatego zakończyłyby się niepowodzeniem. A przynajmniej do czasu wprowadzenia zmian w Team Krypton.
[wizerunek źródło ]
Plik Dostawca weryfikuje scenariusze dostarczone przez konsumenta w środowisku „deweloperskim”. Umożliwia to wymuszanie mikrousług Równoległa zmiana który stwierdza, że należy rozszerzyć funkcjonalność API, a następnie przeprowadzić migrację do nowej wersji. Odnosząc się do wady nr. 2, kody pośredniczące zwykle tworzone przez zespoły zaplecza dla ich własnych wymagań testowych mogą teraz być oparte na scenariuszach konsumenckich przy użyciu Serwer Pact Stub .
Wiążącym elementem obu stron jest „umowa”, którą należy podzielić między zespoły. Pakt zapewnia platformę umożliwiającą udostępnianie umów o nazwie Pośrednik Paktów (dostępne jako usługa zarządzana z Pactflow.io ).
Plik Pośrednik przechowuje dane wyjściowe scenariuszy konsumenckich. Umowa jest następnie przechowywana w brokerze wraz z wersją API. Umożliwia to testowanie na wielu wersjach API, dzięki czemu zgodność może zostać potwierdzona przed wydaniem, co zostało podkreślone w błędzie nr 5.
Dodatkową korzyścią dla Pact Broker w starszych platformach jest widoczność konsumentów. Nie wszyscy konsumenci byli znani autorom API, zwłaszcza nie jest to sposób, w jaki jest on używany.
W szczególności odnosząc się do zdarzenia, w którym obsługiwane były dwie wersje interfejsu API, wystąpił problem z danymi w wersji 1 (V1), który powodował brudne dane w bazie danych.
Zmiana została zaimplementowana w V1 API i wypchnięta do produkcji, jednak konsument polegał na formacie, który powodował problem z danymi, tym samym przerywając integrację z API.
Jak to działa
Powyższy przykład pokazuje przepływ uwierzytelniania, usługa internetowa wymaga od użytkowników uwierzytelnienia w celu uzyskania dostępu do poufnych danych. Usługa internetowa wysyła żądanie do interfejsu API w celu wygenerowania tokenu przy użyciu nazwy użytkownika i hasła. Interfejs API zwraca token okaziciela, który jest dodawany do żądania danych jako nagłówek uwierzytelniania.
Test konsumenta konstruuje żądanie POST dla tokenu, przekazując treść z nazwą użytkownika i hasłem.
Podczas testu uruchamiany jest serwer pozorowany, który sprawdza poprawność skonstruowanego żądania wraz z oczekiwaną odpowiedzią, która w tym przykładzie zawiera wartość tokenu.
Wynik testu konsumenckiego generuje plik umowy paktu. Zostanie to zapisane w brokerze paktów jako wersja 1.
Następnie dostawca pobiera wersję 1 z brokera paktów i odtwarza to żądanie w swoim środowisku lokalnym, weryfikując zgodność żądania i odpowiedzi z wymaganiami konsumenta.
Role i obowiązki
Zapewnienie jakości (QA) / Tester: Tworzenie umów za pomocą Pact.io i współpraca z BA w celu wygenerowania scenariuszy testowych.
Deweloper: Współpraca z działami kontroli jakości przy tworzeniu testów i pomocy w przygotowaniu interfejsu API do implementacji w Continuous Integration (CI).
Analityk biznesowy (licencjat): Generowanie scenariuszy i współpraca z architektem w celu weryfikacji stron, których dotyczy problem.
Architekt rozwiązań (Może nie istnieć w Twojej organizacji): Wprowadzanie zmian w API i koordynacja z BA w zakresie wdrażania, a także komunikowanie zmian konsumentom (korzystanie z Paktu Brokera, aby zrozumieć, kogo to może dotyczyć).
Zarządzanie wersjami: (Tak, wiem, że jest staroświecki, ale nadal istnieje w moim świecie): Pełen pewności, że zmiany zostaną pomyślnie wprowadzone dzięki zakresowi testów kontraktowych.
Cała drużyna: Sprawdź wyniki, aby określić, czy wersje można wypchnąć do produkcji za pomocą narzędzia Pact CLI, Czy mogę wdrożyć .
Testowanie kontraktowe a testowanie integracyjne
Testy integracyjne muszą istnieć, aby sprawdzić, czy system działa przed promocją na środowisko produkcyjne, ale scenariusze można znacznie zmniejszyć.
Skutkiem tego może być:
- Szybsza informacja zwrotna przed wprowadzeniem do środowiska integracji.
- Mniejsze poleganie na stabilności środowiska integracyjnego.
- Mniej środowisk obsługujących wiele wersji API.
- Zmniejszono liczbę niestabilnych instancji środowiska z powodu problemów z integracją.
Integracja | Kontrakt | |
---|---|---|
Wyraźnie wskazać awarię | Wiele warstw | Bardzo łatwe |
Konfiguracja API | tak | Nie rób |
Kontrole wdrażania | tak | Nie rób |
Wersjonowanie API | tak | tak |
Debuguj lokalnie | Nie rób | tak |
Kwestie ochrony środowiska | tak | Nie rób |
Czas opinii | Powolny | Szybki |
Po pierwsze, testowanie kontraktowe nie zastępuje testów integracyjnych. Ale prawdopodobnie może zastąpić niektóre z istniejących scenariuszy testów integracji, przesunąć w lewo i zapewnić szybszą informację zwrotną na temat cyklu życia oprogramowania.
Podczas testowania integracji będziesz weryfikować kontekst, w którym żyje API, taki jak architektura środowiska, proces wdrażania itp.
Dlatego chcesz uruchomić podstawowe scenariusze testów, które potwierdziłyby konfigurację, na przykład, punkt końcowy kontroli kondycji dla wersji interfejsu API. Potwierdzenie również, czy wdrożenie zakończyło się powodzeniem, zwracając odpowiedź 200.
W testowaniu kontraktowym testujesz specyfikę API, która obejmuje przypadki skrajne związane ze strukturą API, zawartością (np. Wartości pól, istnieją klucze) i odpowiedzi na błędy. Na przykład, czy interfejs API obsługuje wartości null, czy też są one usuwane z odpowiedzi interfejsu API (kolejny prawdziwy przykład).
Niektóre korzyści (jeśli jeszcze nie zostały sprzedane)
Poniżej wymieniono niektóre z korzyści, z których można skorzystać przy sprzedaży testów kontraktowych szerszej firmie:
- Szybsze wdrażanie oprogramowania
- Jedno źródło prawdy
- Widoczność wszystkich konsumentów
- Łatwość testowania z różnymi wersjami API.
Często Zadawane Pytania
Niektóre typowe pytania podczas próby przekonania ludzi do przyjęcia testów kontraktowych obejmują:
Pytanie 1) Mamy już 100% pokrycie testów, więc nie jest nam to potrzebne.
Odpowiedź: Cóż, to niemożliwe, ale testowanie kontraktowe ma wiele innych zalet niż tylko pokrycie testów.
Pytanie 2) Za informowanie o zmianach w API odpowiada architekt rozwiązań.
Odpowiedź: Za jakość odpowiada cały zespół.
Pytanie 3) Dlaczego tworzymy scenariusze testowe dla zespołu API?
Odpowiedź: Zespół ds. Interfejsu API nie wie, jak działa usługa internetowa, więc po co miałaby być odpowiedzialna.
P # 4) Nasze kompleksowe testy obejmują cały przepływ od początku do końca, w tym inne punkty integracji.
Odpowiedź: Właśnie dlatego dzielimy testy, aby przetestować jedną rzecz, a Twoim obowiązkiem nie jest testowanie całościowego przepływu systemu, jeśli nie wiesz, jak to działa.
P # 5) W repozytorium jakiego zespołu trwają testy?
jakie typy aplikacji testujemy
Odpowiedź: Obie. Konsument w swoim repozytorium i Dostawca w swoim. Następnie w centralnym punkcie umowa żyje poza którymkolwiek z nich.
Argumenty
Oto argumenty, z którymi trudno nam się spierać, jeśli chodzi o przejście do umowy na test:
- Istnieje już dokumentacja Swagger, której można użyć do wygenerowania testów integracyjnych.
- Zespoły posiadają zarówno usługi front-end, jak i back-end z efektywnym mechanizmem zmian API.
Ciągła integracja
Jak to się ma do zestawu testów ciągłej integracji? Pożądanym miejscem do testowania kontraktowego są testy jednostkowe.
Testy konsumenckie uruchamiają fałszywy serwer, który nie wymaga żadnych zewnętrznych zależności poza testem.
Testy dostawcy wymagają wystąpienia interfejsu API, dlatego lokalny interfejs API można opakować za pomocą pliku serwer testowy w pamięci . Jeśli jednak nie jest łatwo zapakować interfejs API lokalnie, obejście, którego używaliśmy wcześniej, polega na tym, że utworzyliśmy środowisko i wdrożyliśmy kod w tym środowisku w ramach automatycznego sprawdzania żądania ściągnięcia.
[wizerunek źródło ]
Wniosek
W tym samouczku dowiedzieliśmy się, co oznacza testowanie kontraktów i jak wygląda w infrastrukturze mikrousług, a także zobaczyliśmy, jak to wygląda na przykładzie ze świata rzeczywistego.
Wyciągnięto wnioski o tym, jak testowanie kontraktowe może pomóc w przesunięciu testów integracyjnych w lewo. Ponadto widzieliśmy, jak może to obniżyć koszty dla Twojej organizacji poprzez skrócenie czasu opinii zwrotnych związanych z problemami z integracją.
Testowanie kontraktowe to nie tylko narzędzie do testowania technicznego, ale wymusza współpracę zespołów programistycznych poprzez komunikowanie zmian i zachęcanie do testowania jako jednej jednostki. Ogólnie rzecz biorąc, powinno to być warunkiem wstępnym dla każdego, kto chce przejść na ciągłe wdrażanie.
NEXT Tutorial
rekomendowane lektury
- Jak napisać test paktu konsumenckiego w JavaScript
- Zweryfikuj umowę paktową i ciągłe wdrażanie za pomocą interfejsu wiersza polecenia Pact
- Jak opublikować umowę paktową z brokerem paktowym
- Proces ciągłej integracji: jak poprawić jakość oprogramowania i zmniejszyć ryzyko
- Różnice między testowaniem jednostkowym, testowaniem integracyjnym i testowaniem funkcjonalnym
- Co to jest testowanie integracji (samouczek z przykładem testowania integracji)
- 10 najlepszych narzędzi do testowania integracji do pisania testów integracji
- Ciągłe wdrażanie w DevOps