Proč je TestMace lepší než Postman

Proč je TestMace lepší než Postman

Ahoj všichni, tady to máte TestMace! Možná o nás mnoho lidí ví našich předchozí články. Pro ty, kteří se právě připojili: vyvíjíme IDE pro práci s TestMace API. Nejčastější otázkou při porovnávání TestMace s konkurenčními produkty je „Jak se lišíte od Postmana?“ Rozhodli jsme se, že je čas dát na tuto otázku podrobnou odpověď. Níže jsme nastínili naše výhody oproti Listonoš.

Rozdělení na uzly

Pokud pracujete s Postmanem, pak víte, že rozhraní požadavku obsahuje všechny potřebné funkce. Existují skripty, testy a vlastně i samotné požadavky. To usnadňuje začátečníkům, ale ve velkých scénářích tento přístup není flexibilní. Co když chcete vytvořit několik dotazů a provést na nich agregaci? Co když chcete spustit skript bez požadavku nebo několik logicky oddělených skriptů za sebou? Přeci jen je dobré oddělit testy od běžných pomocných skriptů. Přístup „přidat všechny funkce do jednoho uzlu“ navíc není škálovatelný – rozhraní se rychle přetíží.

TestMace zpočátku rozděluje všechny funkce do různých typů uzlů. Chcete podat žádost? To je pro tebe krok požadavku uzel Chcete napsat scénář? To je pro tebe skript uzel Potřebujete testy? Prosím - Tvrzení uzel Ach ano, pořád to celé můžeš zabalit desky uzel A to vše lze mezi sebou snadno kombinovat. Tento přístup je nejen velmi flexibilní, ale také v souladu s principem jediné odpovědnosti umožňuje využívat pouze to, co v danou chvíli skutečně potřebujete. Proč potřebuji skripty a testy, když chci jen podat žádost?

Lidsky čitelný formát projektu

Mezi TestMace a Postman je koncepční rozdíl ve způsobu jejich uložení. V Postman jsou všechny požadavky uloženy někde v místním úložišti. Pokud je potřeba sdílet požadavky mezi více uživateli, pak je třeba použít vestavěnou synchronizaci. Ve skutečnosti je to obecně přijímaný přístup, ale ne bez svých nevýhod. A co bezpečnost dat? Koneckonců, politika některých společností nemusí umožňovat ukládání dat s třetími stranami. Myslíme si však, že TestMace nabízí něco lepšího! A název tohoto vylepšení je „formát projektu čitelný člověkem“.

Začněme tím, že v TestMace v zásadě existuje entita „projekt“. A aplikace byla původně vyvinuta s ohledem na ukládání projektů v systémech správy verzí: strom projektu se téměř jeden na jednoho promítá do struktury souborů, jako formát úložiště se používá yaml (bez dalších závorek a čárek) a souborová reprezentace každého uzlu je podrobně popsána v dokumentaci s komentáři. Ale ve většině případů se tam nepodíváte - všechny názvy polí mají logické názvy.

Co to uživateli dává? To vám umožňuje velmi flexibilně měnit pracovní tok týmu pomocí známých přístupů. Vývojáři mohou například uložit projekt do stejného úložiště jako backend. V pobočkách může vývojář kromě změny samotné kódové základny opravit existující skripty dotazů a testy. Po provedení změn v úložišti (git, svn, mercurial – podle toho, co máte nejraději), CI (vaše oblíbené, nikým nevnucené) spustí naši konzolovou utilitu testmace-clia zpráva přijatá po spuštění (například ve formátu junit, který je podporován také v testmace-cli) je odeslána do příslušného systému. A výše zmíněná bezpečnostní otázka už není problém.

Jak můžete vidět, TestMace nevnucuje svůj ekosystém a paradigma. Místo toho snadno zapadá do zavedených procesů.

Dynamické proměnné

TestMace se řídí konceptem bez kódu: pokud lze problém vyřešit bez použití kódu, snažíme se tuto příležitost poskytnout. Práce s proměnnými je přesně ten druh funkcionality, kdy se ve většině případů obejdete bez programování.

Příklad: obdrželi jsme odpověď ze serveru a část odpovědi chceme uložit do proměnné. V Postmanovi bychom v testovacím skriptu (což je samo o sobě zvláštní) napsali něco jako:

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

Ale podle našeho názoru vypadá psaní skriptu pro tak jednoduchý a často používaný scénář nadbytečně. V TestMace je tedy možné přiřadit část odpovědi do proměnné pomocí grafického rozhraní. Podívejte se, jak je to jednoduché:

Proč je TestMace lepší než Postman

A nyní s každým požadavkem bude tato dynamická proměnná aktualizována. Můžete ale namítnout, že přístup Postman je flexibilnější a umožňuje vám nejen provést zadání, ale také provést určité předběžné zpracování. Zde je návod, jak upravit předchozí příklad:

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

No, pro tento účel TestMace má skript uzel, který pokrývá tento scénář. Chcete-li reprodukovat předchozí případ, ale již spuštěný TestMace, musíte vytvořit uzel skriptu následující po požadavku a jako skript použít následující kód:

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

Jak je vidět, i zde složení uzlů posloužilo dobře. A pro takový jednoduchý případ, jak je popsán výše, můžete výraz jednoduše přiřadit ${crypto.MD5($response.data)} proměnná vytvořená přes GUI!

Vytváření testů přes GUI

Postman umožňuje vytvářet testy psaním skriptů (v případě Postmana je to JavaScript). Tento přístup má mnoho výhod – téměř neomezenou flexibilitu, dostupnost hotových řešení atp.

Realita je však často taková (my nejsme, život je takový), že tester nemá programátorské schopnosti, ale chtěl by týmu přinést užitek právě teď. V takových případech vám TestMace podle konceptu bez kódu umožňuje vytvářet jednoduché testy prostřednictvím GUI, aniž byste se museli uchylovat k psaní skriptů. Zde je například to, jak vypadá proces vytváření testu, který porovnává hodnoty pro rovnost:

Proč je TestMace lepší než Postman

Vytvoření testů v grafickém editoru však tuto možnost nevylučuje psaní testů v kódu. Jsou zde všechny stejné knihovny jako v uzlu skriptu a chai na psaní testů.

Často nastávají situace, kdy je potřeba určitý dotaz nebo dokonce celý skript provést několikrát v různých částech projektu. Příkladem takových požadavků může být vlastní vícestupňová autorizace, uvedení prostředí do požadovaného stavu atd. Obecně řečeno, pokud jde o programovací jazyky, chtěli bychom mít funkce, které lze znovu použít v různých částech aplikace. V TestMace tuto funkci provádí https://trials.autocruitment.com uzel Použití je velmi jednoduché:
1) vytvořte dotaz nebo skript
2) vytvořte uzel typu Link
3) v parametrech zadejte odkaz na skript vytvořený v prvním kroku

V pokročilejší verzi můžete určit, které dynamické proměnné ze skriptu budou předány vyšší úrovni vzhledem k odkazu. Zní to zmateně? Řekněme, že jsme vytvořili složku s názvem vytvořit příspěvek, v rámci kterého je tomuto uzlu přiřazena dynamická proměnná postId. Nyní v uzlu Link create-post-link můžete explicitně určit, že proměnná postId přiřazena k předkovi create-post-link. Tento mechanismus (opět v programovacím jazyce) lze použít k vrácení výsledku z „funkce“. Obecně je to v pohodě, DRY je v plném proudu a opět nebyl poškozen jediný řádek kódu.

Proč je TestMace lepší než Postman

Co se týče Postmana, existuje požadavek na funkci pro opětovné použití požadavků visí od roku 2015a zdá se, že existuje nějaké radyže na tomto problému pracují. Ve své současné podobě má Postman samozřejmě schopnost změnit vlákno provádění, což teoreticky pravděpodobně umožňuje implementovat podobné chování, ale jde spíše o špinavý hack než o skutečně fungující přístup.

Další rozdíly

  • Větší kontrola nad rozsahem proměnných. Nejmenší rozsah, ve kterém lze proměnnou definovat v Postman, je kolekce. TestMace umožňuje definovat proměnné pro jakýkoli dotaz nebo složku. V Postman Share collection umožňuje exportovat pouze kolekce, zatímco v TestMace sdílení funguje pro jakýkoli uzel
  • TestMace podporuje dědičné hlavičky, které lze ve výchozím nastavení nahradit podřízenými dotazy. Pošťák má něco o tomhle: úkola je to dokonce zavřené, ale nabízí se to jako řešení... používat skripty. V TestMace je to vše nakonfigurováno přes GUI a je zde možnost volitelně zakázat zděděné hlavičky u konkrétních potomků
  • Zpět Opakovat. Funguje nejen při úpravách uzlů, ale také při přesouvání, mazání, přejmenovávání a dalších operacích, které mění strukturu projektu
  • Soubory připojené k požadavkům se stávají součástí projektu a jsou s ním uloženy, přičemž jsou na rozdíl od Postmana dokonale synchronizované. (Ano, již nemusíte ručně vybírat soubory při každém spuštění a přenášet je kolegům v archivech)

Funkce, které jsou již na cestě

Nemohli jsme odolat pokušení pozvednout závoj tajemství během příštích vydání, zvláště když je funkčnost velmi chutná a již prochází před vydáním leštěním. Tak se sejdeme.

funkce

Jak víte, Postman používá ke generování hodnot takzvané dynamické proměnné. Jejich seznam je působivý a naprostá většina funkcí se používá ke generování falešných hodnot. Chcete-li například vygenerovat náhodný e-mail, musíte napsat:

{{$randomEmail}}

Protože se však jedná o proměnné (byť dynamické), nelze je použít jako funkce: nejsou parametrizovatelné, proto nebude možné převzít hash z řetězce.

Plánujeme přidat do TestMace „čestné“ funkce. Přímo uvnitř ${} bude možné nejen přistupovat k proměnné, ale také volat funkci. Tito. pokud potřebujete vygenerovat notoricky známý falešný e-mail, jednoduše napíšeme

${faker.internet.email()}

Kromě toho, že se jedná o funkci, si všimnete, že je možné volat metodu na objektu. A místo velkého plochého seznamu dynamických proměnných tu máme sadu logicky seskupených objektů.

Co když chceme vypočítat hash řetězce? Snadno!

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

Všimnete si, že můžete dokonce předávat proměnné jako parametry! V tuto chvíli může zvídavý čtenář tušit, že něco není v pořádku...

Použití JavaScriptu ve výrazech

... A z dobrého důvodu! Když se tvořily požadavky na funkce, najednou jsme došli k závěru, že platný javascript se má psát ve výrazech. Nyní tedy můžete psát výrazy jako:

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

A to vše bez skriptů, přímo ve vstupních polích!

Co se týče Postmana, tak zde lze používat pouze proměnné a při pokusu o zapsání sebemenšího výrazu validátor nadává a odmítá jej vypočítat.

Proč je TestMace lepší než Postman

Pokročilé automatické dokončování

V současné době má TestMace standardní automatické dokončování, které vypadá takto:

Proč je TestMace lepší než Postman

Zde je kromě řádku automatického doplňování uvedeno, k čemu tento řádek patří. Tento mechanismus funguje pouze ve výrazech ohraničených hranatými závorkami ${}.

Jak můžete vidět, byly přidány vizuální značky, které označují typ proměnné (například řetězec, číslo, pole atd.). Můžete také změnit režimy automatického doplňování (například můžete vybrat automatické dokončování s proměnnými nebo záhlavími). Ale ani to není to nejdůležitější!

Za prvé, automatické doplňování funguje i ve výrazech (pokud je to možné). Takhle to vypadá:

Proč je TestMace lepší než Postman

A za druhé, automatické dokončování je nyní dostupné ve skriptech. Podívejte se, jak to funguje!

Proč je TestMace lepší než Postman

Nemá smysl porovnávat tuto funkcionalitu s Postmanem - automatické doplňování je zde omezeno pouze na statické seznamy proměnných, záhlaví a jejich hodnot (opravte mě, pokud jsem na něco zapomněl). Skripty se automaticky nedokončují :)

Závěr

V říjnu uplynul rok od začátku vývoje našeho produktu. Za tuto dobu jsme stihli spoustu věcí a v některých ohledech dohnali naše konkurenty. Ale ať je to jak chce, naším cílem je vytvořit skutečně pohodlný nástroj pro práci s API. Čeká nás ještě hodně práce, zde je hrubý plán rozvoje našeho projektu na nadcházející rok: https://testmace.com/roadmap.

Vaše zpětná vazba nám umožní lépe se orientovat v množství funkcí a vaše podpora nám dodává sílu a jistotu, že děláme správnou věc. Stává se, že dnešek je pro náš projekt důležitým dnem - dnem, kdy byl TestMace zveřejněn ProductHunt. Podpořte prosím náš projekt, je pro nás velmi důležitý. Navíc je dnes na naší stránce PH lákavá nabídka, která je omezená

Zdroj: www.habr.com

Přidat komentář