Ahoj všichni. Pomalu vystupujeme ze stínu a pokračujeme v sérii článků o našem produktu. Po recenzním článku jsme obdrželi mnoho zpětné vazby (většinou pozitivní), návrhů a hlášení o chybách. Dnes si ukážeme v akci a budete moci ocenit některé funkce naší aplikace. Pro úplnější ponoření vám doporučuji nahlédnout do naší dokumentace na adrese . Tak pojďme!
Instalace
Začněme banalitou. Aplikace je dostupná a reálně otestovaná na třech platformách – Linux, Windows, MacOS. Můžete si stáhnout instalační program pro OS, který vás zajímá . Pro uživatele Linuxu je možná instalace . Opravdu doufáme, že se k tomu brzy dostanou Microsoft Store a App Store (Je to nutné? Co myslíte?).
Experimentální scénář
Jako testovací předmět jsme zvolili následující standardní scénář:
- Přihlášení: uživatel - admin, heslo - heslo
- přidat nový záznam
- Zkontrolujeme, zda byl záznam přidán správně
Budeme testovat dál . To je normální , ideální pro testování takových aplikací. Právě jsme přidali autorizaci pomocí tokenu do všech tras json-server a vytvořili jsme způsob přihlášení pro příjem tohoto tokenu. Postupně se budeme pohybovat a postupně zlepšovat náš projekt.
Vytváření projektu a pokus o vytvoření entity bez oprávnění
Nejprve vytvořte nový projekt (Soubor->Nový projekt). Pokud spouštíte aplikaci poprvé, automaticky se otevře nový projekt. Nejprve zkusme zadat požadavek na vytvoření nového záznamu (v případě, že je vytváření záznamů dostupné bez oprávnění). Vyberte položky z místní nabídky uzlu Projekt Přidat uzel -> RequestStep. Nastavte název uzlu na vytvořit příspěvek. V důsledku toho se ve stromu vytvoří nový uzel a otevře se karta pro tento uzel. Nastavíme následující parametry požadavku:
- Typ požadavku: POST
- url:
- Tělo požadavku: json s hodnotou
{"title": "New testmace quick start post"}
Pokud jste udělali vše správně, rozhraní bude vypadat takto:
Pokud se však pokusíme splnit požadavek, server vrátí kód 401 a bez autorizace na tento server nic nedostaneme. No, obecně, podle očekávání).
Přidání požadavku na autorizaci
Jak již bylo řečeno, máme koncový bod POST /login, který bere json jako tělo požadavku formuláře: {"username": "<username>", "password": "<password>"}Kde username и password (opět z úvodního odstavce výše) mají významy admin и password respektive. Jako odpověď tento koncový bod vrátí json like {"token": "<token>"}. Použijeme to k autorizaci. Pojďme tvořit RequestStep uzel s názvem přihlásit se, bude vystupovat jako předek Projekt uzel Pomocí přetažení přesuňte daný uzel ve stromu výše, než je uzel vytvořit příspěvek. Nově vytvořenému požadavku nastavíme následující parametry:
- Typ požadavku: POST
- url:
- Tělo požadavku: json s hodnotou
{"username": "admin", "password": "password"}
Proveďme požadavek a obdržíme dvoustý kód s tokenem v odpovědi. Něco takového:
Refaktoring: odstranění duplikace domény
Požadavky zatím nejsou propojeny do jednoho skriptu. To ale není jediná nevýhoda. Pokud se podíváte pozorně, všimnete si, že alespoň doména je v obou žádostech duplikována. Špatný. Nastal čas refaktorovat tuto část budoucího skriptu a proměnné nám s tím pomohou.
Pro první aproximaci mají proměnné stejnou roli jako v jiných podobných nástrojích a programovacích jazycích – eliminují duplicitu, zvyšují čitelnost atd. Více o proměnných si můžete přečíst v . V tomto případě budeme potřebovat uživatelské proměnné.
Pojďme definovat proměnnou na úrovni uzlu projektu domain s hodnotou https://testmace-quick-start.herokuapp.com. K tomu je to nutné
- Otevřete záložku s tímto uzlem a klikněte na ikonu kalkulačky vpravo nahoře
- Klikněte na + PŘIDAT PROMĚNNÉ
- Zadejte název a hodnotu proměnné
V našem případě bude dialog s přidanou proměnnou vypadat takto:
OK. Nyní, kvůli dědičnosti, můžeme tuto proměnnou použít v potomcích jakékoli úrovně vnoření. V našem případě se jedná o uzly přihlásit se и vytvořit příspěvek. Chcete-li použít proměnnou v textovém poli, musíte napsat ${<variable_name>}. Například přihlašovací adresa URL je převedena na ${domain}/login, respektive pro vytvořit příspěvek url uzlu bude vypadat ${domain}/posts.
Na základě principu DRY jsme tedy scénář mírně vylepšili.
Uložte token do proměnné
Protože se bavíme o proměnných, pojďme si toto téma trochu rozšířit. V tuto chvíli v případě úspěšného přihlášení obdržíme ze serveru autorizační token, který budeme potřebovat v dalších požadavcích. Uložme tento token do proměnné. Protože hodnota proměnné bude určena během provádění skriptu, používáme k tomu speciální mechanismus - .
Nejprve provedeme žádost o přihlášení. V záložce Analyzován odpovědět, najeďte kurzorem na token a v kontextovém menu (které se vyvolá buď pravým tlačítkem myši nebo kliknutím na tlačítko ...) vyberte položku Přiřadit k proměnné. Zobrazí se dialogové okno s následujícími poli:
- Cesta — která část odpovědi je převzata (v našem případě to je
body.token) - Současná cena — jaká hodnota leží podél cesty (v našem případě je to hodnota tokenu)
- Název proměnné — název proměnné kde Současná cena bude zachována. V našem případě tomu tak bude
token - Uzel — ve kterém z předků bude proměnná vytvořena Název proměnné. Vyberme Projekt
Hotový dialog vypadá takto:
Nyní pokaždé, když je uzel spuštěn přihlásit se dynamická proměnná token bude aktualizována o novou hodnotu z odpovědi. A tato proměnná bude uložena v Projekt uzlu a díky dědičnosti bude k dispozici potomkům.
Chcete-li získat přístup k dynamickým proměnným, musíte použít $dynamicVar. Chcete-li například získat přístup k uloženému tokenu, musíte zavolat ${$dynamicVar.token}.
Autorizační token předáváme do požadavků
V předchozích krocích jsme obdrželi autorizační token a vše, co musíme udělat, je přidat záhlaví Authorization se smyslem Bearer <tokenValue> ve všech žádostech vyžadujících autorizaci, včetně vytvořit příspěvek. Existuje několik způsobů, jak to provést:
- Ručně zkopírujte token a přidejte autorizační hlavičku k požadavkům, které vás zajímají. Metoda funguje, ale její použití je omezeno pouze na požadavky typu „vyrobeno a zahozeno“. Není vhodné pro opakované provádění skriptů
- Použijte funkcionalitu .
- Chcete-li použít
Použití druhé metody se zdá být zřejmé, ale v kontextu tohoto článku je tento přístup... nezajímavý. No, opravdu: autorizační mechanismus plus mínus je vám známý z jiných nástrojů (i když máme věci jako ) a je nepravděpodobné, že by vyvolával otázky.
Další věcí jsou výchozí hlavičky! Stručně řečeno, výchozí záhlaví jsou zděděná záhlaví HTTP, která jsou ve výchozím nastavení přidána k požadavku, pokud nejsou výslovně zakázána. Pomocí této funkce můžete například implementovat vlastní autorizaci nebo se jednoduše zbavit duplicit ve skriptech. Využijme tuto funkci k předání tokenu v hlavičkách.
Dříve jsme token prozíravě ukládali do dynamické proměnné $dynamicVar.token na úrovni uzlu projektu. Zbývá pouze provést následující:
- Definujte výchozí název
Authorizations hodnotouBearer ${$dynamicVar.token}na úrovni uzlu projektu. Chcete-li to provést, musíte v rozhraní projektu uzlu otevřít dialog s výchozími nadpisy (tlačítko Záhlaví v pravém horním rohu) a přidejte odpovídající název. Dialog s vyplněnými hodnotami bude vypadat takto:
- Zakázat tuto hlavičku v požadavku na přihlášení. Je to pochopitelné: v době přihlášení ještě nemáme token a nainstalujeme jej s tímto požadavkem. Proto v přihlašovacím rozhraní požadavku v záložce Záhlaví v oblasti Zděděný zrušte zaškrtnutí záhlaví Autorizace.
To je vše. Nyní bude autorizační hlavička přidána ke všem požadavkům, které jsou potomky uzlu Projekt, kromě přihlašovacího uzlu. Ukazuje se, že v této fázi již máme připravený scénář a stačí jej pouze spustit. Skript můžete spustit výběrem Běh v kontextové nabídce uzlu Projekt.
Kontrola správnosti vytvoření příspěvku
V této fázi se náš skript může přihlásit a pomocí autorizačního tokenu vytvořit příspěvek. Musíme se však ujistit, že nově vytvořený příspěvek má správný název. To je v podstatě vše, co zbývá, je udělat následující:
- Odeslat žádost o příjem příspěvku podle ID,
- Zkontrolujte, zda se jméno přijaté ze serveru shoduje se jménem odeslaným při vytváření příspěvku
Podívejme se na první krok. Protože se hodnota id určuje během provádění skriptu, musíte vytvořit dynamickou proměnnou (nazvěme ji postId) z uzlu vytvořit příspěvek na úrovni uzlu projektu. Už víme, jak to udělat, stačí se podívat do sekce Uložte token do proměnné. Zbývá pouze vytvořit požadavek na příjem příspěvku pomocí tohoto id. Chcete-li to provést, vytvořte RequestStep get-post s následujícími parametry:
- Typ požadavku: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
Pro realizaci druhého kroku se musíme seznámit s uzel. Uzel Assertion je uzel, který vám umožňuje psát kontroly pro konkrétní požadavky. Každý uzel Assertion může obsahovat několik asercí (kontrol). Více o všech typech tvrzení si můžete přečíst v našem . budeme používat Compare tvrzení s operátorem equal. Existuje několik způsobů, jak vytvořit tvrzení:
- Dlouho. Ručně vytvořte uzel Assertion z místní nabídky uzlu RequestStep. Ve vytvořeném uzlu Assertion přidejte tvrzení, které vás zajímá, a vyplňte pole.
- Rychle. Vytvořte uzel Assertion spolu s asercí z odpovědi uzlu RequestStep pomocí kontextové nabídky
Použijme druhý způsob. Takto to bude vypadat v našem případě.
Pro ty, kteří to nechápou, tady je to, co se děje:
- Zadejte požadavek v uzlu get-post
- V záložce Analyzován odpovědět, vyvolejte kontextové menu a vyberte Vytvořte tvrzení -> POROVNEJTE -> Rovnat se
Gratulujeme, vytvořili jsme náš první test! Jednoduché, že? Nyní můžete skript úplně spustit a užít si výsledek. Zbývá jen trochu přefaktorovat a vyndat title do samostatné proměnné. Ale to necháme jako domácí úkol)
Závěr
V této příručce jsme vytvořili plnohodnotný scénář a zároveň jsme si prohlédli některé funkce našeho produktu. Samozřejmě jsme nevyužili všechny funkce a v následujících článcích přineseme podrobný přehled možností TestMace. Zůstaňte naladěni!
PS Pro ty, kteří jsou příliš líní reprodukovat všechny kroky, jsme laskavě zaznamenali s projektem z článku. Můžete to otevřít pomocí Soubor -> Otevřený projekt a vyberte složku Project.
Zdroj: www.habr.com