Cześć wszystkim! Dziś chcielibyśmy przedstawić nasz produkt — IDE do pracy z API dla społeczności IT. Niektórzy z was mogą już o nas słyszeć z Jednak nie było kompleksowego przeglądu narzędzia, więc eliminujemy ten uciążliwy niedobór.
Motywacja
Chcielibyśmy zacząć od tego, jak w ogóle doszło do powstania tego projektu i zdecydowaliśmy się stworzyć nasze narzędzie do zaawansowanej pracy z API. Zacznijmy od listy funkcji, które powinno oferować narzędzie, które naszym zdaniem można określić jako "IDE do pracy z API":
- Tworzenie i wykonywanie zapytań oraz skryptów (sekwencji zapytań)
- Pisanie różnego rodzaju testów
- Generowanie testów
- Praca z opisami API, w tym import z takich formatów jak Swagger, OpenAPI, WADL itp.
- Mokowanie zapytań
- Dobra obsługa jednego lub kilku języków programowania do pisania skryptów, w tym integracja z popularnymi bibliotekami
- itd.
Listę można uzupełniać według uznania. Ważne jest, aby stworzyć nie tylko samo IDE, ale także określoną infrastrukturę, jak chociażby synchronizacja w chmurze, narzędzia wiersza poleceń, usługa monitorowania online itp. W końcu trendy ostatnich lat wymagają od nas nie tylko zaawansowanej funkcjonalności aplikacji, ale także przyjemnego interfejsu.
Dla kogo przydatne jest takie narzędzie? Oczywiście dla wszystkich, którzy mają związek z rozwojem i testowaniem API — programistów i testerów =). I chociaż dla pierwszych często wystarczy wykonywanie pojedynczych zapytań i prostych scenariuszy, to dla testerów jest to jedno z podstawowych narzędzi, które oprócz tego powinno obejmować potężny mechanizm pisania testów z możliwością ich uruchamiania w CI.
Zatem, podążając za tymi wskazówkami, zaczęliśmy tworzyć nasz produkt. Przyjrzyjmy się, co osiągnęliśmy na tym etapie.
Szybki start
Rozpocznijmy od pierwszego zapoznania się z aplikacją. Można ją pobrać . Obecnie wspierane są wszystkie 3 główne platformy — Windows, Linux, MacOS. Pobieramy, instalujemy, uruchamiamy. Przy pierwszym uruchomieniu możecie zobaczyć następujące okno:
Kliknij plusik w górnej części obszaru treści, aby utworzyć pierwsze zapytanie. Zakładka z zapytaniem wygląda następująco:
Przyjrzyjmy się temu dokładniej. Interfejs zapytań przypomina interfejs popularnych klientów REST, co ułatwia migrację z podobnych narzędzi. Wykonajmy pierwsze zapytanie na url
Na pierwszy rzut oka panel odpowiedzi również nie przynosi żadnych niespodzianek. Zwrócę jednak uwagę na kilka kwestii:
- Treść odpowiedzi ma formę drzewa, co po pierwsze zwiększa informacyjność, a po drugie pozwala na dodanie kilku interesujących funkcji, o których poniżej
- Jest zakładka Assertions, w której wyświetlany jest lista testów dla tego zapytania
Jak można zauważyć, nasze narzędzie można wykorzystać jako wygodnego klienta REST. Nie zebralibyśmy się tutaj, gdyby jego możliwości ograniczały się tylko do wysyłania zapytań. Poniżej przedstawiam podstawowe pojęcia i funkcjonalności TestMace.
Podstawowe pojęcia i możliwości
Węzeł
Funkcjonalność TestMace podzielona jest na różne typy węzłów. Na przykładzie powyżej pokazaliśmy działanie węzła RequestStep. Obecnie w aplikacji dostępne są również następujące typy węzłów:
- RequestStep. To węzeł, za pomocą którego można stworzyć zapytanie. Jako element podrzędny może mieć tylko jeden węzeł Assertion.
- Assertion. Węzeł służy do pisania testów. Może być elementem podrzędnym tylko dla węzła RequestStep.
- Folder. Pozwala grupować węzły Folder i RequestStep.
- Project. To węzeł główny, tworzony automatycznie podczas tworzenia projektu. W pozostałym zakresie powtarza funkcjonalność węzła Folder.
- Link. Odnośnik do węzła Folder lub RequestStep. Pozwala na ponowne wykorzystanie zapytań i scenariuszy.
- itd.
Węzły znajdują się w scratches (panel po lewej na dole, służy do szybkiego tworzenia «jednorazowych» zapytań) oraz w project (panel po lewej na górze), na którym skupimy się dokładniej.
Projekt
Podczas uruchamiania aplikacji mogłeś zauważyć jedną linię Project w lewym górnym rogu. To korzeń drzewa projektu. Przy uruchomieniu projektu tworzy się tymczasowy projekt, którego ścieżka zależy od twojego systemu operacyjnego. W każdej chwili możesz przenieść projekt w dogodną dla siebie lokalizację.
Głównym celem projektu jest możliwość zapisywania prac w systemie plików oraz dalsza synchronizacja za pośrednictwem systemów kontroli wersji, uruchamiania scenariuszy w CI, przeglądania zmian itd.
Zmienne
Zmienne to jeden z kluczowych mechanizmów aplikacji. Ci z Was, którzy pracują z narzędziami takimi jak TestMace, być może już zrozumieli, o czym mowa. Tak więc zmienne to sposób przechowywania wspólnych danych i komunikacji między węzłami. Przykładem mogą być zmienne środowiskowe w Postmanie lub Insomnia. Jednak posunęliśmy się dalej i rozwinęliśmy temat. W TestMace zmienne można ustawiać na poziomie węzła. Każdego. Istnieje także mechanizm dziedziczenia zmiennych od przodków i nadpisywania zmiennych w potomkach. Ponadto istnieje szereg wbudowanych zmiennych, których nazwy zaczynają się od $. Oto niektóre z nich:
$prevStep— odniesienie do zmiennych poprzedniego węzła$nextStep— odniesienie do zmiennych następnego węzła$parent— to samo, ale dla przodka$response— odpowiedź od serwera$env— bieżące zmienne środowiskowe$dynamicVar— zmienne dynamiczne, tworzone podczas wykonywania skryptu lub zapytania
$env — to w zasadzie zwykłe zmienne na poziomie węzła projektu, jednak zestaw zmiennych środowiskowych zmienia się w zależności od wybranego środowiska.
Dostęp do zmiennej odbywa się przez ${variable_name}
Jako wartość zmiennej może być inna zmienna lub nawet całe wyrażenie. Na przykład, jako zmienna url może być wyrażenie postaci
http://${host}:${port}/${endpoint}.
Osobno warto zaznaczyć możliwość przypisywania zmiennych podczas wykonywania skryptu. Na przykład często zachodzi potrzeba przechowania danych autoryzacyjnych (tokenu lub całego nagłówka), które przyszły z serwera po pomyślnym logowaniu. TestMace pozwala na przechowanie takich danych w dynamicznych zmiennych jednego z przodków. Aby uniknąć kolizji z już istniejącymi 'statycznymi' zmiennymi, zmienne dynamiczne zostały przeniesione do osobnego obiektu. $dynamicVar.
Scenariusze
Wykorzystując wszystkie wymienione możliwości, można wykonywać całe scenariusze zapytań. Na przykład, stworzenie encji -> zapytanie o encję -> usunięcie encji. W tym przypadku na przykład można użyć węzła Folder do grupowania kilku węzłów RequestStep.
Autouzupełnianie i podświetlenie wartości wyrażenia
Aby wygodnie pracować z zmiennymi (i nie tylko), niezbędne jest autouzupełnianie. Oczywiście przyda się również podświetlenie wartości wyrażenia, aby łatwiej i wygodniej ustalić, do czego odnosi się konkretna zmienna. To jest ten przypadek, kiedy lepiej raz zobaczyć niż sto razy usłyszeć:
Warto zauważyć, że autouzupełnianie działa nie tylko dla zmiennych, ale także na przykład dla nagłówków, wartości określonych nagłówków (na przykład autouzupełnianie dla nagłówka Content-Type), protokołów i wielu innych. Lista jest stale uzupełniana w miarę rozwoju aplikacji.
Cofnij / powtórz
Cofanie/powtarzanie zmian to bardzo wygodna funkcja, jednak z jakiegoś powodu realizowana jest daleko nie wszędzie (a narzędzia do pracy z API nie są wyjątkiem). Ale nie u nas!) Cofnij/powtórz jest zaimplementowane w całym projekcie, co pozwala na anulowanie nie tylko edytowania konkretnego węzła, ale także jego tworzenia, usuwania, przenoszenia, itd. Najbardziej krytyczne operacje wymagają potwierdzenia.
Tworzenie testów
Za tworzenie testów odpowiada węzeł Assertion. Jedną z głównych cech jest możliwość tworzenia testów bez programowania, z wykorzystaniem wbudowanych edytorów.
Węzeł Assertion składa się z zestawu assertion-ów (twierdzeń). Każdy assertion ma swój typ, obecnie istnieje kilka typów assertion-ów.
Porównaj wartości — po prostu porównuje 2 wartości. Jest kilka operatorów porównania: „równa”, „nie równa”, „większa”, „większa lub równa”, „mniejsza”, „mniejsza lub równa”.
Zawiera wartość — sprawdza, czy podciąg występuje w ciągu.
XPath — sprawdza, czy w XML według selektora leży określona wartość.
JavaScript assertion — dowolny skrypt w języku JavaScript, który zwraca true w przypadku sukcesu i false w przypadku niepowodzenia.
Zauważę, że tylko ostatni wymaga od użytkownika umiejętności programowania, pozostałe 3 assertion-y są tworzone za pomocą interfejsu graficznego. Oto, jak wygląda okno tworzenia assertion-u porównania wartości:
Kwiatkiem na torcie jest szybkie tworzenie assertion-ów z odpowiedzi, tylko spójrz na to!
Jednak takie assertion-y mają oczywiste ograniczenia, w obliczu których możesz użyć assertion-u JavaScript. I tutaj TestMace również zapewnia wygodne środowisko z autouzupełnianiem, podświetleniem składni i nawet z analizatorem statycznym.
Opis API
TestMace umożliwia nie tylko korzystanie z API, ale także jego dokumentowanie. Opis ma hierarchiczną strukturę i naturalnie wpasowuje się w pozostałą część projektu. Co więcej, obecnie istnieje możliwość importowania opisu API z formatów Swagger 2.0 / OpenAPI 3.0. Opis nie leży jedynie bezczynnie, ale jest ściśle zintegrowany z innymi częściami projektu, co umożliwia automatyczne uzupełnianie URL-i, nagłówków HTTP, parametrów zapytań i innych elementów. W przyszłości planujemy również dodać testy zgodności odpowiedzi z opisem API.
Udostępnianie węzłów
Przykład: chcesz udostępnić problematyczne zapytanie lub nawet cały scenariusz koledze lub po prostu załączyć je do błędu. TestMace pokrywa również ten przypadek: aplikacja pozwala na zserializowanie dowolnego węzła, a nawet poddrzewa do URL-u. Kopiuj-wklej i już łatwo przeniosłeś zapytanie na inny komputer lub projekt.
Czytelny format przechowywania projektów
Obecnie każdy węzeł jest przechowywany w osobnym pliku z rozszerzeniem yml (jak w przypadku węzła Assertion) lub w folderze o nazwie węzła, która zawiera plik index.yml.
Oto jak wygląda przykład pliku z zapytaniem, które zrobiliśmy w powyższym przeglądzie:
index.yml
children: []
variables: {}
type: RequestStep
assignVariables: []
requestData:
request:
method: GET
url: 'https://next.json-generator.com/api/json/get/NJv-NT-U8'
headers: []
disabledInheritedHeaders: []
params: []
body:
type: Json
jsonBody: ''
xmlBody: ''
textBody: ''
formData: []
file: ''
formURLEncoded: []
strictSSL: Inherit
authData:
type: inherit
name: Scratch 1Jak widać, wszystko jest jasne. W razie potrzeby taki format można komfortowo edytować ręcznie.
Hierarchia folderów w systemie plików w pełni odzwierciedla hierarchię węzłów w projekcie. Na przykład scenariusz wyglądający na:
Mapuje się w systemie plików na następującą strukturę (pokazana jest tylko hierarchia folderów, ale można zrozumieć sens)
Co ułatwia proces przeglądu projektu.
Import z Postman
Przeczytawszy wszystko powyższe, niektórzy użytkownicy mogą chcieć spróbować (prawda?) nowego produktu lub (czego diabeł nie zrobi!) w pełni wykorzystać go w swoim projekcie. Jednak migrację mogą wstrzymać liczne zasoby w tym samym Postmanie. W takich przypadkach TestMace wspiera import kolekcji z Postmana. Obecnie wspierany jest import bez testów, jednak w przyszłości nie wykluczamy ich wsparcia.
Plany
Mam nadzieję, że wielu z tych, którzy dotarli do tego momentu, zainteresował nasz produkt. To jednak nie koniec! Prace nad produktem idą pełną parą i oto kilka funkcji, które planujemy dodać wkrótce.
Synchronizacja w chmurze
To jedna z najbardziej poszukiwanych funkcji. Obecnie oferujemy użycie systemów kontroli wersji jako formę synchronizacji, dlatego format jest bardziej przyjazny dla tego typu przechowywania. Jednak nie wszystkim taki sposób pracy odpowiada, dlatego planujemy dodać znany wielu mechanizm synchronizacji przez nasze serwery.
CLI
Jak już wspomniano, produkty na poziomie IDE nie obejdą się bez różnorakich integracji z istniejącymi aplikacjami lub workflow. CLI jest niezbędne do integracji testów napisanych w TestMace w procesie continuous integration. Prace nad CLI idą pełną parą, wczesne wersje będą uruchamiały projekt z prostym raportem w konsoli. W przyszłości planujemy dodać wyjście raportu w formacie JUnit.
System wtyczek
Mimo potęgi naszego narzędzia, zestaw przypadków wymagających rozwiązania jest nieograniczony. Ostatecznie istnieją zadania specyficzne dla konkretnego projektu. Dlatego planujemy dodać SDK do rozwoju wtyczek, co pozwoli każdemu deweloperowi dodać funkcjonalność według własnych upodobań.
Rozszerzenie asortymentu typów węzłów
Ten zestaw węzłów nie pokrywa wszystkich przypadków potrzebnych użytkownikowi. Węzły, które planujemy dodać:
- Węzeł Script — przekształca i umieszcza dane, korzystając z JS i odpowiedniego API. Używając tego typu węzła, można stworzyć na przykład skrypty pre-request i post-request w Postman.
- Węzeł GraphQL — wsparcie dla GraphQL
- Custom assertion węzeł — umożliwi rozszerzenie zestawu dostępnych asercji w projekcie
Oczywiście, to nie jest ostateczna lista, będzie ona na bieżąco uzupełniana, również dzięki Waszym opiniom.
FAQ
Czym różnicie się od Postman?
- Koncepcja węzłów, która pozwala na praktycznie nieograniczone skalowanie funkcjonalności projektu
- Czytelny format projektu z zachowaniem go w systemie plików, co ułatwia pracę z wykorzystaniem systemów kontroli wersji
- Możliwość tworzenia testów bez programowania oraz bardziej zaawansowane wsparcie dla JS w edytorze testów (autouzupełnianie, analiza statyczna)
- Zaawansowane automatyczne uzupełnianie i podświetlanie bieżącej wartości zmiennych
Czy to produkt open-source?
Nie, obecnie źródła są zamknięte, jednak w przyszłości rozważamy możliwość ich udostępnienia.
Na czym zarabiacie?)
Obok wersji gratisowej planujemy wydać płatną wersję produktu. W pierwszej kolejności będą w niej rzeczy, które wymagają części serwerowej, na przykład synchronizacja.
Podsumowanie
Nasz projekt z każdym dniem zbliża się do stabilnego wydania. Już teraz można korzystać z produktu, a pozytywne opinie naszych wczesnych użytkowników to potwierdzają. Aktywnie zbieramy opinie, ponieważ bez bliskiej współpracy z społecznością nie można stworzyć dobrego narzędzia. Można nas znaleźć tutaj:
Czekamy z niecierpliwością na Wasze sugestie i propozycje!
Źródło: habr.com
