
Ahojte všetci. Pomaly sa vraciame do hry a pokračujeme v sérii článkov o našom produkte. Po prehľadnej článku sme dostali množstvo spätných väzieb (predovšetkým pozitívnych), návrhov a bug reportov. Dnes vám ukážeme v akcii a oceníte niektoré funkcie našej aplikácie. Pre úplné ponorenie sa odporúčam pozrieť našu dokumentáciu na adrese . Tak poďme na to!
Inštalácia
Začneme s banalitami. Aplikácia je dostupná a skutočne testovaná na troch platformách – Linux, Windows, MacOS. Môžete si stiahnuť inštalačný program pre zaujímavý OS z . Pre linuxových užívateľov je možnosť inštalácie . Dúfame, že sa čoskoro dostaneme aj do Microsoft Store a App Store (je to potrebné? Čo si myslíte?).
Testovací scénar
Pre náš experiment sme vybrali nasledujúci štandardný scenár:
- prihlásime sa: používateľ – admin, heslo – password
- pridáme novú položku
- skontrolujeme správne pridanú položku
Testovať budeme na . Je to bežný , ktorý je výborne vhodný na testovanie podobných aplikácií. Iba sme pridali autorizáciu pomocou tokenu na všetky trasy json-server-a a vytvorili metódu login na získanie tohto tokenu. Budeme pokračovať systematicky, postupne zdokonaľujeme náš projekt.
Vytvorenie projektu a pokus o vytvorenie entity bez autorizácie
Na začiatok vytvoríme nový projekt (File->Nový projekt). Ak spúšťate aplikáciu po prvý raz, nový projekt sa otvorí automaticky. Najprv sa pokúsime vykonať požiadavku na vytvorenie novej položky (možno že vytváranie položiek je dostupné bez autorizácie). Vyberte v kontextovej ponuke uzla Project položky Pridať uzol -> RequestStep. Ako názov uzla zadajte create-post. V dôsledku toho sa v strome vytvorí nový uzol a otvorí sa karta tohto uzla. Nastavíme nasledujúce parametre požiadavky:
- Typ požiadavky: POST
- url:
- Telo požiadavky: json s hodnotou
{"title": "New testmace quick start post"}
Ak ste všetko urobili správne, rozhranie bude vyzerať takto:

Ale ak sa pokúsime vykonať požiadavku, server vráti kód 401 a bez autorizácie na tomto serveri nič nezíska. No, v podstate očakávané).
Pridanie požiadavky na autorizáciu
Ako už bolo povedané, máme POST endpoint /login, ktorý prijíma ako telo požiadavky json typu: {"username": "", "password": ""}, kde username a password (opäť, z úvodného textu vyššie) majú významy admin a password prislúchajúco. V odpovedi tento endpoint vracia JSON vo forme {"token": ""}. Využijeme ho na autorizáciu. Vytvoríme RequestStep uzol s názvom login, ako predok bude vystupovať Projekt uzol. Pomocou funkcie drag-and-drop presuňte tento uzol v hierarchii nad uzol create-post. Novovytvorenému požiadavku nastavíme nasledujúce parametre:
- Typ požiadavky: POST
- url:
- Telo požiadavky: json s hodnotou
{"username": "admin", "password": "password"}
Vykonáme požiadavok a dostaneme dvesto kód s tokenom v odpovedi. Takto nejako:

Refaktoring: odstraňujeme duplicitu domény
Zatiaľ požiadavky nie sú prepojené do jedného scenára. Ale to nie je jediná nevýhoda. Ak sa pozrieme pozorne, môžeme si všimnúť, že minimálne doména je duplikovaná v oboch požiadavkách. Nepríjemné. Je čas refaktorovať túto časť budúceho scenára a v tom nám pomôžu premenné.
Na prvý pohľad premenné vykonávajú rovnakú úlohu ako v iných podobných nástrojoch a programovacích jazykoch – odstraňujú duplicity, zvyšujú čitateľnosť atď. Viac o premenných si môžete prečítať v . V tomto prípade potrebujeme používateľské premenné.
Definujeme na úrovni projektu uzla premennú domain s hodnotou https://testmace-quick-start.herokuapp.com. Na to je potrebné
- Otvoríme kartu s týmto uzlom a klikneme na ikonu kalkulačky vpravo hore
- Kliknite na + ADD VARIABLE
- Zadajte názov a hodnotu premennej
V našom prípade bude dialóg s pridanou premennou vyzerať takto:

OK. Teraz vďaka dedičnosti môžeme túto premennú používať v potomkoch akéhokoľvek úrovne zloženia. V našom prípade sú to uzly login a create-post. Na to, aby sme v textovom poli použili premennú, je potrebné napísať ${}. Napríklad, URL pre prihlásenie sa premení na ${domain}/login, pričom pre create-post uzol URL bude vyzerať ako ${domain}/posts.
Týmto spôsobom, riadiac sa zásadou DRY, sme trochu vylepšili scénar.
Uložíme token do premennej
Keďže sme otvorili diskusiu o premenných, poďme sa tejto téme venovať trochu viac. V súčasnosti, ak sa prihlásenie uskutoční úspešne, dostaneme od servera autentifikačný token, ktorý bude potrebný v nasledujúcich požiadavkách. Uložme tento token do premennej. Keďže hodnota premennej sa určuje počas vykonávania scenára, použijeme na to špeciálny mechanizmus – .
Na začiatok vykonáme požiadavku na prihlásenie. Vo вкладke Parsed odpovede umiestnite kurzor na token a v kontextovej ponuke (ktorá sa aktivuje pravým tlačidlom myši alebo stlačením tlačidla …) vyberte položku Priradiť k premennej. Objaví sa dialóg s nasledujúcimi poliami:
- Cesta — ktorý kúsok odpovede sa berie (v našom prípade je to
body.token) - Aktuálna hodnota — aká hodnota leží podľa cesty Cesta (v našom prípade je to hodnota tokenu)
- Názov premennej — názov premennej, kde Aktuálna hodnota sa bude ukladať. V našom prípade to bude
token - Node — v ktorom z predkov sa vytvorí premenná Názov premennej. Vyberieme Projekt
Vyplnený dialóg vyzerá nasledovne:

Teraz pri každom vykonaní uzla login dynamická premenná token sa bude aktualizovať novou hodnotou z odpovede. A táto premenná bude uložená v Projekt uzle a vďaka dedeniu bude dostupná potomkom.
Aby ste sa mohli obrátiť na dynamické premenné, je potrebné použiť $dynamicVar. Napríklad, aby ste sa dostali k uloženému tokenu, je potrebné zavolať ${$dynamicVar.token}.
Posielame autorizačný token v požiadavkách
Na predchádzajúcich krokoch sme získali autorizačný token a všetko, čo je potrebné urobiť, je pridať hlavičku Authorization s hodnotou Bearer do všetkých požiadaviek, ktoré vyžadujú autorizáciu, vrátane v create-post. Na to existuje niekoľko spôsobov:
- Ručne skopírovať token a pridať autorizačnú hlavičku do požiadaviek. Tento spôsob je funkčný, avšak jeho použitie sa obmedzuje iba na požiadavky typu „urobil a hodil“. Na mnohonásobné vykonávanie scenárov sa nehodí.
- Využiť funkciu .
- Použiť
Použitie druhého spôsobu sa zdá zrejmé, avšak v kontexte tohto článku sa takýto prístup… nezdá byť zaujímavý. Nuž, naozaj: mechanizmus autorizácie je vám plus mínus známy z iných nástrojov (hoci máme aj také veci ako ) a pravdepodobne nevyvolá otázky.
Iné sú veci predvolené hlavičky! Jednoducho povedané, predvolené hlavičky sú dedičné z rodičovských HTTP hlavičiek, ktoré sa automaticky pridávajú k požiadavke, pokiaľ nie sú výslovne vypnuté. S touto funkciou môžeme napríklad implementovať vlastnú autorizáciu alebo sa jednoducho zbaviť duplicity v scenároch. Túto funkciu použijeme na posielanie tokenu v hlavičkách.
Predtým sme si opatrne uložili token do dynamickej premennej $dynamicVar.token na úrovni Project uzla. Ostáva spraviť nasledujúce:
- Určiť predvolenú hlavičku
Authorizations hodnotouBearer ${$dynamicVar.token}na úrovni Project uzla. Na to je potrebné v rozhraní Project uzla otvoriť dialóg s predvolenými hlavičkami (tlačidlo Headers v pravom hornom rohu) a pridať príslušnú hlavičku. Dialóg so vyplnenými hodnotami bude vyzerať nasledovne:

- Vypnúť túto hlavičku z login požiadavky. To je jasné: v momente prihlásenia ešte nemáme token a touto požiadavkou ho práve nastavíme. Preto v rozhraní login požiadavky na karte Headers v oblasti Inherited odškrtneme políčko pri hlavičke Authorization.
Na tom všetkom. Teraz sa hlavička autorizácie pridá do všetkých požiadaviek, ktoré sú potomkami Project uzla, okrem login uzla. Vyzerá to tak, že v tejto fáze už máme pripravený scenár a ostáva len to spustiť. Scenár môžeme spustiť zvolením položky Spustiť v kontextovom menu Project uzla.
Kontrolujeme správnosť vytvorenia príspevku
V tejto fáze náš scenár vie prihlasovať a, pomocou autorizačného tokenu, vytvárať príspevky. Avšak musíme sa uistiť, že novo vytvorený príspevok má správne meno. V podstate ostáva spraviť nasledujúce:
- Poslať požiadavku na získanie príspevku podľa id,
- Skontrolovať, že meno odoslané zo servera zodpovedá menu, ktoré bolo zaslané pri vytváraní príspevku.
Pozrime sa na prvý krok. Keďže hodnota id sa určuje počas vykonávania skriptu, je potrebné vytvoriť dynamickú premennú (nazvime ju postId) z uzla create-post na úrovni Project uzla. Ako to urobiť už vieme, stačí sa obratiť na sekciu Uložíme token do premennej. Ostáva len vytvoriť požiadavku na získanie príspevku podľa tohto id. Na to vytvoríme RequestStep get-post s nasledujúcimi parametrami:
- Typ požiadavky: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
Na uskutočnenie druhého kroku sa musíme zoznámiť s uzlom. Assertion uzol je uzol, ktorý umožňuje písať kontroly na určité požiadavky. Každý Assertion uzol môže obsahovať niekoľko tvrdení (kontrol). Viac o všetkých typoch assertion-ov sa dozviete v našom . Budeme používať Compare assertion s operátorom equal. Existuje niekoľko spôsobov tvorby assertion-ov:
- Dlhý. Ručne z kontextového menu uzla RequestStep vytvoriť uzol Assertion. Vytvorenom Assertion uzle pridať zaujímajúci assertion a vyplniť polia.
- Rýchly. Vytvoriť uzol Assertion spolu s assertion-om z odpovede uzla RequestStep pomocou kontextového menu.
Využijeme druhý spôsob. Takto to bude vyzerať pre náš prípad.

Pre tých, ktorí tomu nerozumejú, tu sa deje nasledovné:
- Vykonať požiadavku v uzle get-post
- Na karte Parsed odpovede vyvolať kontextové menu a vybrať Create assertion -> Compare -> Equal
Gratulujem, vytvorili sme prvý test! Jednoduché, však? Teraz môžete spustiť skript úplne a užívať si výsledok. Ostáva iba trocha refaktorovať a vyniesť title do samostatnej premennej. Ale toto necháme na vás ako domácu úlohu)
Záver
V tejto príručke sme vytvorili plnohodnotný skript a zároveň sa zaoberali niektorými funkciami nášho produktu. Samozrejme, využili sme ďaleko nie všetky funkcie a v nasledujúcich článkoch pripravíme podrobný prehľad možností TestMace. Sledujte aktualizácie!
P.S. Pre tých, ktorí sú leniví opakovať všetky kroky, sme ochotne pripravili s projektom z článku. Otvoriť ho môžete pomocou File -> Open project a vybrať priečinok Project.
Zdroj: habr.com

