Autor: Michał Chytroszek – prelegent ProMEET#23 w Katowicach
3 min read
Autor: Michał Chytroszek – prelegent ProMEET#23 w Katowicach
3 min read
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.
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:
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?
Czy zmieniła się ilość testów? Nie. Czy zmieniły się jakiś sposób poziomy? Również nie. Zmieniła się tylko przejrzystość odpowiedzialności. Każda część naszego systemu jest traktowana jaka osobna aplikacja z osobną bazą testów. Jakie są zalety takiego rozwiązania?
Jeśli przekonamy się do takiego podejścia, naturalnie zaczniemy pisać testy na poziomie wywołań API. Częściej będziemy zastanawiać się gdzie umiejscowiona jest logika, którą weryfikujemy. Czy jest to UI czy backend naszego systemu? Przerzucenie dużej części testów na wysyłanie żądań do serwisów pomoże rozwiązać nam niektóre problemy związane z warstwą wizualną aplikacji:
Dobrze, zdecydowaliśmy się stworzyć bazę testów w warstwie API.
Pierwszym sposobem, który może przyjść nam do głowy jest użycie wywołań serwisów w warunkach wstępnych naszych testów UI. Ile razy stworzyliśmy testy, w których samo przygotowanie środowiska trwało więcej niż weryfikacja danego przypadku? Dzięki przeniesieniu tej logiki do warstwy komunikacyjnej jesteśmy w stanie znacznie przyspieszyć wykonywanie tych najwolniejszych testów. Innym zastosowaniem jest stałe tworzenie danych testowych na naszym środowisku. Zaoszczędzi, to również nasz czas podczas manualnej weryfikacji systemu.
Testy API często są niedoceniane oraz brakuje nam zaufania do nich. Jednak wiele z ich zalet może usprawnić naszą codzienną pracę.
A gdzie podziały się Twoje testy API?
Michał Chytroszek