Witajcie wszyscy. Powoli wychodzimy z cienia i kontynuujemy serię artykułów o naszym produkcie. Po poprzednim artykułach przeglądowych otrzymaliśmy wiele opinii (przeważnie pozytywnych), sugestii oraz raportów błędów. Dziś zaprezentujemy TestMace w akcji i będziesz mógł ocenić niektóre funkcje naszej aplikacji. Dla pełniejszego zanurzenia polecamy zapoznanie się z naszą dokumentacją pod adresem http://docs-ru.testmace.com. No to zaczynamy!

Instalacja

Zacznijmy od oczywistości. Aplikacja jest dostępna i naprawdę testowana na trzech platformach — Linux, Windows, MacOS. Możesz pobrać instalator dla interesującego Cię systemu operacyjnego z naszej strony. Dla użytkowników Linuksa istnieje możliwość instalacji pakietu snap. Mamy nadzieję, że wkrótce znajdą się zasoby na Microsoft Store i App Store (a potrzebne? Co sądzicie?).

Scenariusz testowy

Jako testowany wybierzemy następujący standardowy scenariusz:

• zalogujemy się: użytkownik — admin, hasło — password
• dodamy nowy wpis
• sprawdzimy poprawne dodanie wpisu

Będziemy testować na https://testmace-quick-start.herokuapp.com/. To zwykły json-server, doskonały do testowania podobnych aplikacji. Dodaliśmy tylko autoryzację za pomocą tokenu do wszystkich tras json-servera i stworzyliśmy metodę login dla uzyskania tegoż tokenu. Będziemy działać stopniowo, sukcesywnie udoskonalając nasz projekt.

Tworzenie projektu i próba utworzenia encji bez autoryzacji

Na początek stwórzmy nowy projekt (Plik->Nowy projekt). Jeśli uruchamiasz aplikację po raz pierwszy, nowy projekt otworzy się automatycznie. Najpierw spróbujmy wysłać żądanie dotyczące utworzenia nowego wpisu (może dodawanie wpisów jest dostępne bez autoryzacji). Wybierz w menu kontekstowym węzła Project opcje Dodaj węzeł -> RequestStep. Jako nazwę węzła ustawimy create-post. W rezultacie w drzewie zostanie utworzony nowy węzeł i otworzy się karta tego węzła. Ustawmy następujące parametry żądania:

• Typ żądania: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Treść żądania: json z wartością {"title": "Nowy post szybkiego startu testmace"}
  Jeśli wszystko zrobiłeś poprawnie, interfejs będzie wyglądał następująco:

Jednak jeśli spróbujemy wykonać żądanie, serwer zwróci kod 401 i bez autoryzacji nie uzyskamy nic na tym serwerze. Cóż, w sumie można się było tego spodziewać).

Dodajemy żądanie autoryzacji

Jak już wspomniano, mamy punkt końcowy POST /login, który przyjmuje jako treść żądania json w postaci: {"username": "", "password": ""}, gdzie nazwa użytkownika i hasło (znów, z powyższej wprowadzenia) mają znaczenie admin i hasło odpowiednio. W odpowiedzi ten endpoint zwraca json w postaci {"token": ""}. Skorzystamy z niego do autoryzacji. Stworzymy RequestStep węzeł o nazwie login, jako rodzica w tym przypadku będzie pełnił rolę Projekt węzeł. Za pomocą przeciągnij i upuść przenieś ten węzeł w drzewie wyżej niż węzeł create-post. Ustalmy nowo utworzonemu żądaniu następujące parametry:

• Typ żądania: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Treść żądania: json z wartością {"username": "admin", "password": "password"}

Wykonamy zapytanie i otrzymamy dwusetny kod z tokenem w odpowiedzi. Tak to wygląda:

Refaktoryzacja: usuwamy duplikację domeny

Na razie zapytania nie są połączone w jeden scenariusz. Ale to nie jedyny problem. Jeśli się przyjrzeć, można zauważyć, że przynajmniej domena jest duplikowana w obu zapytaniach. To nie jest dobre. Nadszedł czas, aby zrefaktoryzować tę część przyszłego scenariusza, a w tym pomogą nam zmienne.

W przybliżeniu zmienne pełnią tę samą rolę, co w innych podobnych narzędziach i językach programowania — eliminacja duplikacji, zwiększenie czytelności itd. Więcej o zmiennych można przeczytać w naszej dokumentacji. W tym przypadku potrzebne będą nam zmienne użytkownika.

Zdefiniujmy na poziomie węzła Projekt zmienną domena o wartości https://testmace-quick-start.herokuapp.com. W tym celu konieczne jest

• Otwórz zakładkę z tym węzłem i kliknij ikonę kalkulatora po prawej górnej stronie
• Kliknij na + DODAJ ZMIENNĄ
• Wprowadź nazwę i wartość zmiennej
  W naszym przypadku dialog z dodaną zmienną będzie wyglądał następująco:

OK. Dzięki dziedziczeniu możemy teraz używać tej zmiennej w potomkach na każdym poziomie zagnieżdżenia. W naszym przypadku są to węzły login i create-post. Aby w polu tekstowym użyć zmiennej, należy napisać ${}. Na przykład, url do logowania przekształca się w ${domain}/login, odpowiednio dla create-post węzła url będzie wyglądać tak ${domain}/posts.

W ten sposób, kierując się zasadą DRY, nieco poprawiliśmy scenariusz.

Zapisujemy token w zmiennej

Skoro już mówimy o zmiennych, rozwiniemy ten temat. W tej chwili w przypadku udanego logowania otrzymujemy od serwera token autoryzacyjny, który będzie nam potrzebny w kolejnych zapytaniach. Zapiszmy ten token w zmiennej. Ponieważ wartość zmiennej będzie określana w czasie wykonywania scenariusza, wykorzystamy do tego specjalny mechanizm — zmienne dynamiczne.

Na początek wykonajmy zapytanie logowania. W zakładce Parsed Aby uzyskać odpowiedź, najedź kursorem na token i w kontekście menu (które wywołuje się prawym przyciskiem myszy lub klikając przycisk …) wybierz opcję Przypisz do zmiennej. Pojawi się okno dialogowe z następującymi polami:

• Ścieżka — jaki fragment odpowiedzi jest brany (w naszym przypadku to body.token)
• Aktualna wartość — jaka wartość znajduje się na ścieżce Ścieżka (w naszym przypadku to wartość tokena)
• Nazwa zmiennej — nazwa zmiennej, do której Aktualna wartość zostanie zapisana. W naszym przypadku będzie to token
• Węzeł — w którym z przodków będzie utworzona zmienna Nazwa zmiennej. Wybierzmy Projekt

Wypełnione okno dialogowe wygląda następująco:

Teraz przy każdym wykonaniu węzła login zmienna dynamiczna token będzie aktualizowana nową wartością z odpowiedzi. A ta zmienna będzie przechowywana w Projekt węźle i dzięki dziedziczeniu będzie dostępna dla potomków.

Aby odwołać się do zmiennych dynamicznych, należy użyć wbudowanej zmiennej $dynamicVar. Na przykład, aby uzyskać dostęp do przechowanego tokena, należy wywołać ${$dynamicVar.token}.

Przekazujemy token autoryzacyjny w zapytaniach

Na wcześniejszych etapach uzyskaliśmy token autoryzacyjny i wszystko, co musimy zrobić, to dodać nagłówek Authorization z wartością Bearer do wszystkich zapytań wymagających autoryzacji, w tym do create-post. Istnieje kilka sposobów na to:

1. Ręcznie skopiuj token i dodaj nagłówek autoryzacyjny do interesujących zapytań. Metoda działa, jednak jej zastosowanie ogranicza się tylko do zapytań typu "zrobiłem i wyrzuciłem". Nie nadaje się do wielokrotnego wykonywania scenariuszy
2. Skorzystać z funkcji autoryzacji.
3. Użyć domyślnych nagłówków

Korzystanie z drugiej metody wydaje się oczywiste, ale w kontekście tego artykułu takie podejście... nie jest interesujące. Naprawdę: mechanizm autoryzacji jest mniej więcej znany z innych narzędzi (mimo że mamy rzeczy takie jak dziedziczenie autoryzacji) i raczej nie wywoła wątpliwości.

Inne są nagłówki domyślne! W skrócie, nagłówki domyślne to nagłówki HTTP dziedziczone od przodków, które są domyślnie dodawane do żądania, jeśli nie zostaną wyraźnie wyłączone. Dzięki tej funkcjonalności można na przykład zrealizować niestandardową autoryzację lub po prostu pozbyć się duplikacji w scenariuszach. Zastosujemy tę funkcję do przekazywania tokena w nagłówkach.

Wcześniej ostrożnie zapisaliśmy token w zmiennej dynamicznej $dynamicVar.token na poziomie węzła Project. Pozostaje wykonać następujące kroki:

1. Zdefiniować nagłówek domyślny Authorization o wartości Bearer ${$dynamicVar.token} na poziomie węzła Project. W tym celu w interfejsie węzła Project należy otworzyć okno dialogowe z nagłówkami domyślnymi (przycisk Headers w prawym górnym rogu) i dodać odpowiadający nagłówek. Okno dialogowe z wypełnionymi wartościami będzie wyglądać następująco:
   
2. Wyłącz ten nagłówek z żądania logowania. Co widać: w momencie logowania nie mamy jeszcze tokena i tym żądaniem właśnie go ustalimy. Dlatego w interfejsie żądania logowania w zakładce Headers w obszarze Inherited odznaczymy pole z nagłówka Authorization.

Na tym kończymy. Teraz nagłówek autoryzacji będzie dodawany do wszystkich żądań, które są potomkami węzła Project, z wyjątkiem węzła logowania. Oznacza to, że na tym etapie mamy już gotowy scenariusz i pozostaje nam go tylko uruchomić. Uruchomić scenariusz można, wybierając opcję Run w menu kontekstowym węzła Project.

Sprawdzamy poprawność tworzenia posta

Na tym etapie nasz scenariusz potrafi się zalogować, a korzystając z tokena autoryzacyjnego, stworzyć posta. Musimy jednak upewnić się, że nowo utworzony post ma poprawną nazwę. To znaczy, że w zasadzie pozostaje wykonać następujące kroki:

• Wysłać żądanie o pobranie posta według id,
• Sprawdzić, czy nazwa, która przyszła z serwera, odpowiada nazwie przesłanej przy tworzeniu posta

Rozważmy pierwszy krok. Ponieważ wartość id jest określana w czasie wykonania skryptu, trzeba stworzyć zmienną dynamiczną (nazwijmy ją postId) z węzła create-post na poziomie węzła Project. Jak to zrobić, już wiemy, wystarczy sięgnąć do sekcji Zapisujemy token w zmiennej. Pozostaje tylko stworzyć żądanie o pobranie posta według tego id. W tym celu stwórzmy RequestStep get-post z następującymi parametrami:

• Typ żądania: GET
• URL: ${domain}\/posts\/${$dynamicVar.postId}

Aby zrealizować drugi krok, musimy zapoznać się z Assertion węzłem. Węzeł Assertion to węzeł, który pozwala na pisanie sprawdzeń dla określonych zapytań. Każdy węzeł Assertion może zawierać kilka stwierdzeń (sprawdzeń). Więcej informacji na temat wszystkich rodzajów assertion-ów znajdziesz w naszej dokumentacji. Będziemy używać Compare assertion z operatorem equal. Istnieje kilka sposobów tworzenia assertion-ów:

1. Długi. Ręcznie z menu kontekstowego węzła RequestStep utworzyć węzeł Assertion. W utworzonym węźle Assertion dodać interesujący assertion i wypełnić pola.
2. Szybki. Utworzyć węzeł Assertion wraz z assertion-om z odpowiedzi węzła RequestStep za pomocą menu kontekstowego

Skorzystamy z drugiego sposobu. Oto jak to będzie wyglądać w naszym przypadku.

Dla tych, którzy nie zrozumieli, tu dzieje się to:

1. Wykonać zapytanie w węźle get-post
2. Na zakładce Parsed odpowiedzi wywołać menu kontekstowe i wybrać Create assertion -> Compare -> Equal

Gratulacje, stworzyliśmy pierwszy test! Proste, prawda? Teraz możesz uruchomić scenariusz w całości i cieszyć się wynikiem. Zostaje tylko odrefaktoryzować i przenieść title do osobnej zmiennej. Ale to pozostawimy wam jako zadanie domowe)

Podsumowanie

W tym przewodniku stworzyliśmy pełnoprawny scenariusz i jednocześnie omówiliśmy kilka funkcji naszego produktu. Oczywiście, nie wykorzystaliśmy w pełni wszystkich funkcji i w kolejnych artykułach przeprowadzimy szczegółowy przegląd możliwości TestMace. Śledź nasze aktualizacje!

P.S. Dla tych, którym się nie chce powtarzać wszystkich kroków, uprzejmie przygotowaliśmy repozytorium z projektem z artykułu. Można je otworzyć za pomocą Plik -> Open project i wybrać folder Project.

Źródło: habr.com