Dlaczego TestMace jest lepszy od Postmana

Dlaczego TestMace jest lepszy od Postmana

Witam wszystkich, proszę bardzo Testuj Maca! Być może wiele osób wie o nas z z naszych poprzedni artykuły. Dla tych, którzy właśnie dołączyli: opracowujemy IDE do współpracy z API TestMace. Najczęściej zadawanym pytaniem przy porównywaniu TestMace z konkurencyjnymi produktami jest: „Czym różnisz się od Postmana?” Uznaliśmy, że czas udzielić szczegółowej odpowiedzi na to pytanie. Poniżej przedstawiliśmy nasze zalety Listonosz.

Podział na węzły

Jeśli współpracujesz z Postmanem, wiesz, że interfejs żądań zawiera wszystkie niezbędne funkcjonalności. Są skrypty, testy i właściwie same zapytania. Ułatwia to początkującym, ale w dużych scenariuszach takie podejście nie jest elastyczne. A co jeśli chcesz utworzyć kilka zapytań i przeprowadzić na nich agregację? A co jeśli chcesz wykonać skrypt bez żądania lub kilka logicznie oddzielonych skryptów z rzędu? Przecież dobrym pomysłem byłoby oddzielenie testów od zwykłych skryptów narzędziowych. Ponadto podejście „dodaj całą funkcjonalność do jednego węzła” nie jest skalowalne – interfejs szybko ulega przeciążeniu.

TestMace początkowo dzieli całą funkcjonalność na różne typy węzłów. Chcesz złożyć wniosek? To dla Ciebie krok żądania węzeł Chcesz napisać scenariusz? To dla Ciebie scenariusz węzeł Potrzebujesz testów? Proszę - twierdzenie węzeł O tak, nadal możesz to wszystko zawinąć falcówka węzeł A wszystko to można łatwo ze sobą połączyć. Takie podejście jest nie tylko bardzo elastyczne, ale także, zgodnie z zasadą pojedynczej odpowiedzialności, pozwala korzystać tylko z tego, czego w danym momencie naprawdę potrzebujesz. Po co mi skrypty i testy, jeśli chcę tylko złożyć wniosek?

Format projektu czytelny dla człowieka

Istnieje koncepcyjna różnica między TestMace i Postman w sposobie ich przechowywania. W Postmanie wszystkie żądania są przechowywane gdzieś w pamięci lokalnej. Jeśli zachodzi potrzeba udostępniania żądań kilku użytkownikom, należy skorzystać z wbudowanej synchronizacji. W rzeczywistości jest to ogólnie przyjęte podejście, choć nie pozbawione wad. A co z bezpieczeństwem danych? Przecież polityka niektórych firm może nie pozwalać na przechowywanie danych u osób trzecich. Uważamy jednak, że TestMace ma coś lepszego do zaoferowania! Nazwa tego ulepszenia to „format projektu czytelny dla człowieka”.

Zacznijmy od tego, że w TestMace w zasadzie istnieje encja „projektowa”. Aplikacja została początkowo opracowana z myślą o przechowywaniu projektów w systemach kontroli wersji: drzewo projektu jest rzutowane niemal jeden na jednego na strukturę pliku, formatem przechowywania jest YAML (bez dodatkowych nawiasów i przecinków), a reprezentacja plikowa każdego węzła jest szczegółowo opisana w dokumentacji wraz z komentarzami. Ale w większości przypadków nie będziesz tam szukać - wszystkie nazwy pól mają nazwy logiczne.

Co to daje użytkownikowi? Dzięki temu możesz bardzo elastycznie zmieniać przebieg pracy zespołu, stosując znane Ci podejścia. Na przykład programiści mogą przechowywać projekt w tym samym repozytorium, co backend. W oddziałach oprócz zmiany samej bazy kodu programista może poprawiać istniejące skrypty zapytań i testy. Po zatwierdzeniu zmian w repozytorium (git, svn, mercurial - co lubisz najbardziej), CI (twój ulubiony, nie narzucony przez nikogo) uruchamia nasze narzędzie konsolowe testmace-cli, a raport otrzymany po wykonaniu (na przykład w formacie junit, który jest również obsługiwany w testmace-cli) jest wysyłany do odpowiedniego systemu. A wspomniana wyżej kwestia bezpieczeństwa nie stanowi już problemu.

Jak widać TestMace nie narzuca swojego ekosystemu i paradygmatu. Zamiast tego łatwo wpasowuje się w ustalone procesy.

Zmienne dynamiczne

TestMace kieruje się koncepcją braku kodu: jeśli problem można rozwiązać bez użycia kodu, staramy się zapewnić taką możliwość. Praca ze zmiennymi to dokładnie ta funkcjonalność, w której w większości przypadków można obejść się bez programowania.

Przykład: otrzymaliśmy odpowiedź z serwera i chcemy część odpowiedzi zapisać w zmiennej. W Postmanie w skrypcie testowym (co samo w sobie jest dziwne) napisalibyśmy coś takiego:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);

Jednak naszym zdaniem pisanie scenariusza dla tak prostego i często używanego scenariusza wydaje się zbędne. Dlatego w TestMace istnieje możliwość przypisania fragmentu odpowiedzi do zmiennej za pomocą interfejsu graficznego. Zobacz jakie to proste:

Dlaczego TestMace jest lepszy od Postmana

A teraz przy każdym żądaniu ta zmienna dynamiczna będzie aktualizowana. Można jednak sprzeciwić się, twierdząc, że podejście Postmana jest bardziej elastyczne i pozwala nie tylko na wykonanie zadania, ale także na wykonanie wstępnego przetwarzania. Oto jak zmodyfikować poprzedni przykład:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));

Cóż, w tym celu ma TestMace scenariusz węzeł, który obejmuje ten scenariusz. Aby odtworzyć poprzedni przypadek, ale już wykonany przez TestMace, musisz utworzyć węzeł skryptu po żądaniu i użyć następującego kodu jako skryptu:

const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));

Jak widać, i tutaj kompozycja węzłów dobrze się sprawdziła. W tak prostym przypadku, jak opisano powyżej, możesz po prostu przypisać wyrażenie ${crypto.MD5($response.data)} zmienna utworzona poprzez GUI!

Tworzenie testów poprzez GUI

Postman umożliwia tworzenie testów poprzez pisanie skryptów (w przypadku Postmana jest to JavaScript). Takie podejście ma wiele zalet – niemal nieograniczoną elastyczność, dostępność gotowych rozwiązań itp.

Często jednak rzeczywistość jest taka (my tacy nie jesteśmy, takie jest życie), że tester nie ma umiejętności programistycznych, a chciałby już teraz przynieść zespołowi korzyść. W takich przypadkach, zgodnie z koncepcją braku kodu, TestMace umożliwia tworzenie prostych testów za pomocą GUI bez konieczności pisania skryptów. Oto przykładowo jak wygląda proces tworzenia testu porównującego wartości pod kątem równości:

Dlaczego TestMace jest lepszy od Postmana

Tworzenie testów w edytorze graficznym nie eliminuje jednak takiej możliwości pisanie testów w kodzie. Znajdują się tu wszystkie te same biblioteki, co w węźle skryptowym i chai do pisania testów.

Często zdarzają się sytuacje, gdy określone zapytanie lub nawet cały skrypt trzeba wykonać kilkukrotnie w różnych częściach projektu. Przykładem takich żądań może być niestandardowa autoryzacja wieloetapowa, doprowadzenie środowiska do pożądanego stanu itp. Ogólnie rzecz biorąc, jeśli chodzi o języki programowania, chcielibyśmy mieć funkcje, które można ponownie wykorzystać w różnych częściach aplikacji. W TestMace tę funkcję pełni link węzeł Jest bardzo łatwy w użyciu:
1) utwórz zapytanie lub skrypt
2) utwórz węzeł typu Link
3) w parametrach podaj link do skryptu utworzonego w pierwszym kroku

W bardziej zaawansowanej wersji można określić, które zmienne dynamiczne ze skryptu mają być przekazywane na wyższy poziom w stosunku do łącza. Brzmi zagmatwanie? Załóżmy, że utworzyliśmy folder o nazwie utwórz post, w ramach którego do tego węzła przypisana jest zmienna dynamiczna postId. Teraz w węźle Link utwórz-post-link możesz wyraźnie określić, że zmienna postId przypisany do przodka utwórz-post-link. Tego mechanizmu (ponownie w języku programowania) można użyć do zwrócenia wyniku z „funkcji”. Ogólnie jest spoko, DRY trwa pełną parą i znowu ani jedna linijka kodu nie została uszkodzona.

Dlaczego TestMace jest lepszy od Postmana

Jeśli chodzi o Postmana, istnieje prośba o funkcję umożliwiającą ponowne wykorzystanie żądań wisi od 2015 rokui wygląda na to, że jest nawet kilka wskazówekże pracują nad tym problemem. W swojej obecnej formie Postman ma oczywiście możliwość zmiany wątku wykonania, co teoretycznie prawdopodobnie umożliwia wdrożenie podobnego zachowania, ale jest to bardziej brudny hack niż naprawdę działające podejście.

Inne różnice

  • Większa kontrola nad zakresem zmiennych. Najmniejszym zakresem, w jakim można zdefiniować zmienną w Postmanie, jest kolekcja. TestMace umożliwia zdefiniowanie zmiennych dla dowolnego zapytania lub folderu. W kolekcji Postman Share możesz eksportować tylko kolekcje, natomiast w TestMace udostępnianie działa dla dowolnego węzła
  • Obsługuje TestMace dziedziczne nagłówki, które domyślnie można zastąpić zapytaniami podrzędnymi. Listonosz ma coś na ten temat: zadanie, i jest nawet zamknięty, ale jest oferowany jako rozwiązanie... używaj skryptów. W TestMace wszystko to konfiguruje się za pomocą GUI i istnieje opcja opcjonalnego wyłączenia dziedziczonych nagłówków w określonych potomkach
  • Cofnij/Ponów. Działa nie tylko podczas edycji węzłów, ale także podczas przenoszenia, usuwania, zmiany nazwy i innych operacji zmieniających strukturę projektu
  • Pliki dołączone do wniosków stają się częścią projektu i są z nim przechowywane, a jednocześnie są doskonale zsynchronizowane, w przeciwieństwie do Postmana. (Tak, nie musisz już ręcznie wybierać plików przy każdym uruchomieniu i przesyłać ich współpracownikom w archiwach)

Funkcje, które są już w drodze

Nie mogliśmy oprzeć się pokusie uchylenia zasłony tajemnicy w przypadku kolejnych wydań, zwłaszcza gdy funkcjonalność jest bardzo smaczna i jest już w fazie dopracowywania przed wydaniem. Więc spotkajmy się.

funkcje

Jak wiadomo, Postman do generowania wartości wykorzystuje tak zwane zmienne dynamiczne. Ich lista jest imponująca a zdecydowana większość funkcji służy do generowania fałszywych wartości. Na przykład, aby wygenerować losowy e-mail, musisz napisać:

{{$randomEmail}}

Ponieważ jednak są to zmienne (aczkolwiek dynamiczne), nie można ich używać jako funkcji: nie można ich parametryzować, dlatego nie będzie możliwe pobranie skrótu z ciągu.

Planujemy dodać „uczciwe” funkcje do TestMace. Bezpośrednio wewnątrz ${} będzie można nie tylko uzyskać dostęp do zmiennej, ale także wywołać funkcję. Te. jeśli chcesz wygenerować notorycznie fałszywy e-mail, po prostu napiszemy

${faker.internet.email()}

Oprócz tego, że jest to funkcja, zauważysz, że istnieje możliwość wywołania metody na obiekcie. Zamiast dużej, płaskiej listy zmiennych dynamicznych mamy zestaw logicznie pogrupowanych obiektów.

A co jeśli chcemy obliczyć skrót ciągu? Łatwo!

${crypto.MD5($dynamicVar.data)}

Zauważysz, że możesz nawet przekazywać zmienne jako parametry! W tym momencie dociekliwy czytelnik może podejrzewać, że coś jest nie tak…

Używanie JavaScript w wyrażeniach

... I nie bez powodu! Kiedy tworzyliśmy wymagania dla funkcji, nagle doszliśmy do wniosku, że prawidłowy JavaScript powinien być zapisywany w wyrażeniach. Teraz możesz swobodnie pisać wyrażenia takie jak:

${1 + '' + crypto.MD5('asdf')}

A wszystko to bez skryptów, bezpośrednio w polach wejściowych!

Jeśli chodzi o Postmana, tutaj możesz używać tylko zmiennych, a gdy próbujesz napisać najmniejsze wyrażenie, walidator przeklina i odmawia jego obliczenia.

Dlaczego TestMace jest lepszy od Postmana

Zaawansowane autouzupełnianie

Obecnie TestMace ma standardowe autouzupełnianie, które wygląda następująco:

Dlaczego TestMace jest lepszy od Postmana

Tutaj, oprócz linii autouzupełniania, wskazane jest, do czego należy ta linia. Mechanizm ten działa tylko w wyrażeniach otoczonych nawiasami ${}.

Jak widać, dodano znaczniki wizualne, które wskazują typ zmiennej (na przykład ciąg znaków, liczba, tablica itp.). Możesz także zmienić tryby autouzupełniania (na przykład możesz wybrać autouzupełnianie zmiennymi lub nagłówkami). Ale nawet to nie jest najważniejsze!

Po pierwsze, autouzupełnianie działa nawet w wyrażeniach (jeśli to możliwe). Oto jak to wygląda:

Dlaczego TestMace jest lepszy od Postmana

Po drugie, autouzupełnianie jest teraz dostępne w skryptach. Zobacz jak to działa!

Dlaczego TestMace jest lepszy od Postmana

Nie ma sensu porównywać tej funkcjonalności z Postmanem - autouzupełnianie ogranicza się tam jedynie do statycznych list zmiennych, nagłówków i ich wartości (poprawcie mnie, jeśli o czymś zapomniałem). Skrypty nie są automatycznie uzupełniane :)

wniosek

W październiku minął rok od rozpoczęcia rozwoju naszego produktu. W tym czasie udało nam się zrobić wiele rzeczy i pod pewnymi względami dogonić naszych konkurentów. Tak czy inaczej, naszym celem jest stworzenie naprawdę wygodnego narzędzia do pracy z interfejsami API. Przed nami jeszcze sporo pracy, oto przybliżony plan rozwoju naszego projektu na nadchodzący rok: https://testmace.com/roadmap.

Twoja opinia pozwoli nam lepiej poruszać się po wielu funkcjach, a Twoje wsparcie da nam siłę i pewność, że postępujemy właściwie. Tak się składa, że ​​dzisiaj jest ważny dzień dla naszego projektu - dzień, w którym ukazał się TestMace ProductHunt. Prosimy o wsparcie naszego projektu, jest to dla nas bardzo ważne. Co więcej, na naszej stronie PH znajduje się dziś kusząca oferta, która jest ograniczona

Źródło: www.habr.com

Dodaj komentarz