Jak wykonać zewnętrzne testy API (blackbox)

14

Załóżmy, że używasz interfejsów API od dostawcy, jak upewnić się, że ich interfejs API działa zgodnie z oczekiwaniami?

Czasami moim głównym zmartwieniem jest to, że sprzedawca wypycha zmiany do swojego kodu i łamie API, chcemy mieć jakieś automatyczne oprogramowanie do ich ciągłego testowania. Jak sobie z tym poradzić?

testing api rest continuous-integration integration-tests użytkownik34401
źródło
W zależności od języka mogą istnieć narzędzia, które mogą pomóc (myślę, że Pex dla bibliotek / API C #).
Steven Evers,

Odpowiedzi:

10

Krótka odpowiedź: potrzebujesz pakietu testowego dla interfejsu API dostawcy zewnętrznego - więc będziesz musiał go opracować.

Nie oczekuj, że ktoś zrobi to za Ciebie i nie oczekuj „magicznej kuli” do automatycznego generowania odpowiednich testów.

Niektóre rzeczy, które możesz wypróbować dodatkowo:

  • zapytaj sprzedawcę, czy zapewnia listę „przełomowych zmian” dla każdej nowej wersji
  • zapytaj ich, jak dbają o kompatybilność API / poinformuj ich, że jest to ważna funkcja dla Ciebie
  • sprawdź, czy interfejs API zapewnia określone haki testowania, dane wyjściowe rejestrowania lub coś podobnego dla części, których nie można łatwo przetestować
  • zawijaj ważne wywołania interfejsu API własnym kodem rejestrowania, zapisując dane wejściowe i powiązane dane wyjściowe interfejsu API w pliku dziennika, ułatwi to debugowanie rzeczy, jeśli wydarzy się coś nieoczekiwanego
  • dodaj asercje do wywołań interfejsu API, aby sprawdzić warunki wstępne i końcowe, więc jeśli nowa wersja interfejsu API pokazuje nieoczekiwane zachowanie w aplikacji, otrzymasz wczesny komunikat o błędzie

Jeśli te rzeczy działają, czy nie, zależy od tego, kto jest twoim dostawcą i jakiego rodzaju interfejsu API masz na myśli. Interfejs API, który generuje pewne dane wyjściowe, takie jak pliki, jest o wiele łatwiejszy do przetestowania niż interfejs API, który kontroluje niektóre urządzenia fizyczne, na których trzeba obserwować zachowanie rzeczy, aby zdecydować, czy wywołanie API zakończyło się powodzeniem, czy nie.

Doktor Brown
źródło
Całkowicie się zgadzam, ale wydaje mi się, że pytający nie ma doświadczenia z testowaniem jednostek i nie zna schematu pracy z nimi. Mam na myśli: znajdź punkty krytyczne, napisz jednostki testowe, uruchom wszystkie testy, debuguj, podczas debugowania znajdź nowe punkty krytyczne, napisz nowe jednostki, powtórz ostatnie 4 kroki po każdej zmianie API.
Gangnus,
@Gangnus: IMHO OP nie powiedział nam nic o swoich wcześniejszych doświadczeniach z testami jednostkowymi. Jeśli ma z tym problemy, jestem pewien, że wie o bardziej szczegółowym pytaniu. Co więcej, tematem tutaj nie są „testy jednostkowe”, ale „testy automatycznej integracji”. Wymagają one zazwyczaj innego schematu niż, na przykład, testowanie jednostkowe w stylu TDD.
Doc Brown
Tak, nie powiedział tego. Ale jeśli zapyta „jak upewnić się, że ich interfejs API działa zgodnie z oczekiwaniami”, nie wspominając o testach, „wydaje mi się”, że ich nie zna. Jeśli chodzi o automatyczne testy integracji, nie zna ich nawet z większym prawdopodobieństwem, wspomniał tylko o „jakimś automatycznym oprogramowaniu”. Czekasz na ludzi o tych samych umiejętnościach co twoja, ale w tych tematach 99% programistów (w tym ja) wie znacznie mniej. i 90% o wiele znacznie mniej.
Gangnus,
0

Oparty na frazowaniu plakatu, to coś więcej niż tylko testowanie, IMO. Po napisaniu testu jednostkowego interfejsu API i upewnieniu się, że wszystko działa zgodnie z oczekiwaniami, należy monitorować interfejsy API innych firm, aby wykryć problemy, zanim zrobią to użytkownicy. Takie jest prawdziwe ryzyko związane z interfejsami API innych firm - to nie jest twój kod i nie masz kontroli nad tym, ile testów przeprowadzono na interfejsie API ani kiedy / jeśli się zmieni.

(Zastrzeżenie: używane tutaj nazwy produktów) Jeśli używasz soapUI do pisania testów API, testy te mogą być ponownie użyte w AlertSite jako monitor operacyjny, aby upewnić się, że API działa zgodnie z oczekiwaniami. Jeśli test się nie powiedzie, możesz zostać ostrzeżony, zanim użytkownicy zadzwonią do Ciebie i narzekają, że Twoja aplikacja nie działa.

Lorinda Brandon
źródło
0

Zaimplementuj testy edukacyjne dla swojego obszaru zainteresowań (funkcje, których planujesz używać). Testy uczenia się są testami integracji napisanymi przez programistę na podstawie publicznej umowy API. Testy nie powinny być zapisywane w oparciu o wewnętrzne szczegóły implementacji, nawet jeśli kod źródłowy interfejsu API jest dostępny. Ten rodzaj testów uczenia się służy dwóm celom -

  1. Znacząco poprawia to zrozumienie interfejsu API innej firmy.
  2. Testy pomagają zweryfikować, czy zgłoszona nowa wersja jest rzeczywiście wstecznie kompatybilna, czy nie.
Anand Patel
źródło
0

Istnieją 2 podejścia do tego problemu ...

Twoja aplikacja działa w środowisku produkcyjnym przy rzeczywistym ruchu użytkowników:

jeśli masz produkowaną aplikację, która ma ruch na żywo i zależy od zewnętrznego interfejsu API, nie masz innego wyboru, jak uważne monitorowanie i posiadanie dobrych progów, aby wiedzieć jak najszybciej, kiedy zewnętrzny interfejs dokonuje zmian bez powiadamiania.

zawsze należy wziąć pod uwagę, że:

  • zmiana interfejsu API w czasie
  • sprzedawca interfejsu API może mieć błędy
  • Zestawy testowe dostawców interfejsu API mogą zawierać błędy lub nie obejmować w pełni wszystkich funkcji interfejsu API produkcji

Twoja aplikacja jest instalacją i ma zaplanowane wersje / wydania:

w tym przypadku masz okres karencji, aby zawieść ... użytkownik na żywo nie ma wpływu na zmiany w zewnętrznych interfejsach API.

moim zdaniem jest to łatwiejsze zadanie. napisz test (pełny test end-to-end), który dokonuje prawdziwych transakcji / http / żądań do aplikacji, która wywołuje zewnętrzny interfejs API i sprawdza, czy nie ma żadnych awarii. bez zestawów testowych bez fałszywych transakcji.

po wykonaniu tego zadania możesz je uruchamiać co 24 godziny, 1 minutę itp.

dobre praktyki:

  • zautomatyzować wszystko
  • mieć osobę, z którą możesz szybko skontaktować się ze sprzedawcą zewnętrznego interfejsu API
  • nie ślepo ufaj sprzedawcy przetestuj wszystko
  • szybko się nie powiedzie - jeśli twoja usługa zależy w dużej mierze od zewnętrznego interfejsu API, nie pozwól jej ulec awarii. szybko się nie powiedzie i zwróci prawidłowe komunikaty o błędach

przybory:

Nimrod007
źródło