Gdzie się podziały testy API?

API w aplikacjach

W czasach popularności mikroserwisów coraz częściej spotykamy się ze zwrotem API w testowanych przez nas aplikacjach. Coraz częściej również, w początkowej fazie testów używamy narzędzi takich jak Postman lub SoapUI, w celu weryfikacji odpowiedzi zwracanych przez nasze serwisy. Co jednak z automatyzacją takich testów? Gdy otwieramy dzisiaj ogłoszenia dla testera automatyzującego pierwszym słowem kluczowym, które rzuca się w oczy najczęściej jest: Selenium. Czasem i to raczej w sekcji mile widziane niż wymagane, pojawia się API lub REST. Wygląda na, to że umiejętności powiązane z tą warstwą testów są na dalszym planie dla pracodawców.

Jak to wygląda w klasycznej piramidzie testów?

Tutaj testy API możemy znaleźć na jej środkowym poziomie. Czy są mniej ważne od tych związanych z warstwą GUI? Oczywiście, że nie, dodatkowo ich umiejscowienie w piramidzie wskazuje, na potrzebę stworzenia większej ich ilości niż tych „klikanych”. W tym momencie pojawia się problem odpowiedzialności za testy. W przypadku testów jednostkowych sytuacja jest dosyć prosta – tworzą je najczęściej deweloperzy. W większości przypadków, opiekunami testów UI są testerzy. Co jednak z integracją? Dużą część tego typu testów tworzą deweloperzy, często zaślepiając zewnętrzne serwisy. Z drugiej strony testerzy tworzą swoje scenariusze e2e, również działając na poziomie API. Tym sposobem wprowadzamy chaos, który powoduje, że projekcie już nikt nie wie co i jak jest testowane.

Kolejnym problemem pojawiającym się na naszej drodze jest fakt, że rzadko kiedy stosunek testów w naszym projekcie zbliża się do tego docelowego. Jeśli pracujemy przy testach starszej aplikacji to nasza piramida może wyglądać tak:

Jeśli pojawiła się silna potrzeba automatyzacji testów i nasze próby ograniczyły się do zautomatyzowania tylko manualnych przypadków, skończyło się to tak:

W tym momencie ktoś może zapytać – czy to źle? Nasze testy regresji są w większości zautomatyzowane. Weryfikacja kolejnej wersji oprogramowania nie trwa już tydzień, a tylko jedną noc. Czy są jakieś wady tego rozwiązania? Niestety tak, główne z nich to:

• Długi czas wykonywania. Poprzednio wspomniałem o redukcji z siedmiu do jednej nocy. Nadal jednak nie pozwala nam to na szybką weryfikację w awaryjnej sytuacji, gdy zmuszeni jesteśmy wydać krytyczną poprawkę. Wciąż pozostanie nam czekanie długich godzin lub ryzykowna instalacja.
• Stabilność, a raczej jej brak. Im dłużej nasze testy się wykonują tym większe prawdopodobieństwo zaburzenia ich rezultatów z powodu niestabilności środowiska testowego. Jeśli często zaczynamy dzień od żmudnego odfiltrowywania rzeczywistych błędów od zwykłych timeoutów coraz więcej testów kończy z adnotacją disabled.
• Duża wrażliwość na błędy. Jeśli w UI naszej aplikacji wystąpił błąd, który zablokuje wykonywanie naszych testów, są one tyle samo warte co manualna weryfikacja. Mimo tego, że są zautomatyzowane, nadal musimy czekać na poprawką oraz jej instalację na środowisku testowym.

Czy możemy te problemy rozwiązać w prosty sposób? Dużą pomocą będzie zmiana podejścia do testowanych aplikacji. Architektura naszego systemu może wyglądać następująco:

Mamy tutaj warstwę wizualną naszego systemu, kontaktujący się z wyspecjalizowanymi serwisami.

Moim zdaniem powszechnym błędem jest myślenie o tej konstrukcji jako pojedynczej aplikacji i tak samo traktowanie jej testów.

Co gdyby odrobinę zmienić podejście?