Wstęp

Zapraszamy do ciekawostek i podsumowania sprintu Płetwal🐳 z tygodni 36/37 (06.09.2022-19.09.2022). Dzisiaj będzie mocno tematycznie – o REST API 😎

Testerskie linki

  1. Strategie testowania REST API to mocny oręż w ręku testera. Na początek prezentujemy najbardziej mroczną VADER:
    • Verbs: Testuj wszystkie możliwe metody: Get, Post, Put, Patch, Delete, Head itd
    • Authorisation: Czy wszystkie wrażliwe zasoby są zabezpieczone, czy logowanie działa poprawnie?
    • Data: Czy przesyłane dane mają poprawny format, wielkość i czy odpowiadają wymaganiom biznesowym?
    • Errors: Statusy błędów i ich poprawne opisy to minimum. Czy API dobrze informuje o napotkanych błędach?
    • Responsiveness: Czy nasz serwis odpowiada w założonym czasie, czy ilość danych w serwisie ma na to wpływ, czy wszystkie operacje są równie szybkie?

    Krótki i treściwy post prezentujący ten model:
    Call Darth VADER to help you test the APIs

  2. Istnieje jeszcze jedna dobra strategia: POISED. W skrócie:
    • Parameters: Manipulacja parametrami i ich wartościami to bardzo prosta i wydajna technika testów REST API. Na początek wystarczy je po prostu usuwać 😀
    • Output: Gdy już rozkręcamy się z testami warto sprawdzić, czy API odpowiada nam w zakładany sposób. Może wyrzuca z siebie dziwne błędy z backendu albo puste wiadomości?
    • Interop: Sprawdzamy integrację pomiędzy zapytaniami czy innym serwisami. Czy usunięcie użytkownika spowoduje problem z dostępem do powiązanych z nim zasobów?
    • Security: Sprawdzamy autoryzacje i autentykację. Czy można wykonać operacje na zabezpieczonych zasobach bez zalogowania się?
    • Errors: Intencjonalne wprowadzenie błędów i oczekiwane rezultaty. REST API powinno nas jasno informować jaki jest błąd (brakujące pole, niepoprawna wartość etc.) wraz ze stosownym statusem odpowiedzi oraz zgodnie z dokumentacją
    • Data: Czy wrzucenie dużej ilości danych nie zakłóci działania serwisu? Jakie są maksymalne wielkości danych dla pojedynczego payload, czy wszystko poprawnie zapisuje się w backendzie?

    Tutaj grafika podsumowująca POISED:

    Autorką strategii jest Amber Race Senior Software Development Engineer in Test w Big Fish Games.

  3. Poziomy dojrzałości REST API – dla każdego projektu implementującego (REST) API możemy określić poziom dojrzałości za pomocą modelu Richardsona (ang. Richardson Maturity Model). Model ten określa 4 poziomy.
    • Poziom: 0: API nie spełnia założeń dla stylu architektury REST. Do tego poziomu zaliczamy protokół SOAP i RPC.
    • Poziom: 1: Zasoby podzielone na niezależne ścieżki.
    • Poziom: 2: W wielu firmach REST API zostaje na poziomie 2, gdyż poziom 3 niesie ze sobą wiele dodatkowych złożoności… Dopiero na tym poziomie pojawia się implementacja metod jak GET, POST, PUT oraz DELETE.
    • Poziom: 3: Tutaj pojawiają się bardzie złożone implementacje, jak dynamiczne linkowanie zasobów w odpowiedziach API.

    Żródło: https://devopedia.org/richardson-maturity-model

    O modelu dojrzałości poczytasz w poniższych postach:

Co nowego u nas?

  1. Webinar 5 TECHNIK TESTÓW REST API zakończył się ogromnym sukcesem😎 Mieliśmy kilkaset osób na live a prawie tysiąc testerów, którzy dołączyli do listy zainteresowanych, już odebrało materiały o soczystych technikach testowania backendu!
    Jeśli chcesz otrzymać nagranie i materiały z webinaru – możesz to zrobić na stronie 5 TECHNIK TESTÓW REST API.
  2. Nasz najnowszy Program Podstawy Testowania REST API jest już po oficjalnej premierze. Zostało tylko kilka dni aby do niego przystąpić. Warto dołączyć teraz, gdyż nie planujemy powrotu przez następnych kilka miesięcy (i w obecnej cenie😎).
  3. Do Programu Podstawy Testowania REST API dodaliśmy całkowicie nowy kurs. Zawiera on materiał, w którym pokazujemy od całkowitych podstaw jak napisać własną aplikację z REST API. Najważniejsze, że wystartujesz z tematem bardzo szybko i z narzędziami które poznajesz w Programie.

    Zaczynamy od przygotowania projektu, instalacji bibliotek, implementacji pierwszy endpointów… aż po prosty frontend wraz z dokumentacją w Swaggerze!🤯 Materiał ten pozwoli naszym kursantom dobrze poznać oraz zrozumieć zasadę działania REST API oraz pokaże dlaczego testy API są tak ważne w projektach.

Rozwój

  1. Przemek:: Dzisiaj będzie nie o książkach, a o testach na backendzie i REST API w tle.

    Intro

    Jakiś czas temu serwis Vimeo, z którego udostępniamy wideo do naszych Programów nauczania dla testerów, wdrożył ciekawą funkcję. Mianowicie chodzi o autogenerowanie napisów do wideo. Nowe możliwości są super… ale nie zawsze.

    Mroczna strona narzucania zmian

    Wszystko byłoby super, gdyby nie dwie rzeczy.

    Po pierwsze autogenerowanie działa tylko dla języka angielskiego. Ok, szkoda, że nie wspierają języka polskiego, ale rozumiem jaki język jest najpopularniejszy na świecie (mandaryński?😉).

    Po drugie: w serwisie Vimeo wdrożono tę funkcję automatycznie do wszystkich nowo dodawanych wideo! Niestety nie byłem świadomy, że taka funkcja pojawi się w naszym playerze wideo😅 Wdrażając ponad 450 lekcji z Programu Podstawy Testowania REST API w pewnym momencie zorientowaliśmy się, że nowe lekcje otrzymały taki przycisk:

    Umożliwia on kursantowi włączenie napisów… które z treścią lekcji nie mają nic wspólnego – próba wyłuskania angielskich słów z polskiej wymowy raczej się nie sprawdza.

    Vimeo niestety nie udostępnia możliwości globalnego wyłączenia tej funkcji dla wideo, które już otrzymały napisy😢 Można ręcznie wyłączyć tą opcję dla danego wideo i zajmuje to parę minut. Przejście przez wszystkie wideo Programu Podstawy Testowania Rest API nie wchodziło w grę…

    Aby jak najszybciej pozbyć się problemu z tajemniczym przyciskiem po pierwsze postanowiłem przeszukać sieć. Natrafiłem na dobre pytanie na największym forum programistycznym na świecie czyli stackoverflow.com. Pytający miał dokładnie ten sam problem z Vimeo co ja. Niestety, odpowiedzi na pytanie nie było.

    REST API na ratunek

    Na szczęście Vimeo posiada REST API – a my na jaktestowac.pl umiemy w REST API😎😎😎
    Właściwie co tu dużo pisać: aktywnie testujemy i korzystanie z wielu funkcji Vimeo poprzez REST API.

    Dokumentacja API Vimeo może nie jest najpiękniejsza, ale po chwili wyszukiwania udało się znaleźć odpowiednie opisy zasobów API związanych z tajemniczym przyciskiem CC. Następnie zakodziłem prosty skrypt w Pythonie i…

    Wyłączenie niechcianej opcji dla jednego z kursów (69 lekcji wideo) zajęło zaledwie 60 sekund. To jest właśnie moc REST API i umiejętnego korzystania z backendu💪 Uaktualniłem w ten sposób wszystkie kursy z Programu praktycznie w kilka minut.

    Dzielenie się wiedzą

    Przy okazji interakcji z backendem i REST API Vimeo utwierdziłem się w przekonaniu, że jest to bardzo przydatna wiedza. Znajomość standardu REST API pomaga nie tylko zaoszczędzić czas, ale i uzyskać dostęp do funkcji, które dla zwykłego śmiertelnika (użytkownika frontendu GUI) nie są dostępne.

    Wróćmy jeszcze na chwilę do pytania na stackoverflow.com, które dotyczyło problemu z niechcianym przyciskiem w playerze. Dodałem odpowiedź, przekazując tam całą wiedzę jaką uzyskałem w związku z tajemniczym przyciskiem CC na Vimeo. Zawarłem tam kod, linki do dokumentacji i przykłady: stackoverflow.com API

    Na koniec

    REST API może nie jest najprostsza technologią, a każda implementacja jest odrobinę inna. Posiadając jednak podstawową wiedzę z zakresu działania REST API, można nie tylko dobrze się bawić przy testach ale i praktycznie ułatwić sobie życie. Czego i Tobie testerze z całego serca życzę👩‍💻

Wracamy do pracy

Po tej garści aktualności i ciekawostek wracamy do pracy nad nowymi soczystymi materiałami. Do usłyszenia niebawem! 👋

Chcesz poznać
tajniki testowania REST API?
Zobacz nasz najnowszy Program! 👇

Zachęcamy również do zajrzenia na naszą tablicę trello, gdzie możesz monitorować ogólne postępy prac nad nowymi materiałami jak i również głosować na nowe tematy. Pamiętaj, że dostęp do najnowszych wieści od jaktestowac.pl uzyskasz obserwując nas na facebooku, twitterze i od niedawna również na instagramie 😉

Stay tuned!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *