Hej allihopa. Vi börjar sakta men säkert komma ut ur skuggorna och fortsätta artikelserien om vår produkt. Efteråt. tidigare recensionsartikeln, vi fick mycket feedback (mestadels positiv), förslag och felrapporter. Idag kommer vi att visa TestMace i praktiken och du kommer att kunna uppskatta några av funktionerna i vår applikation. För en mer fullständig fördjupning rekommenderar jag att du läser vår dokumentation på http://docs-ru.testmace.comSå, låt oss köra!

Installation

Låt oss börja med grunderna. Appen är tillgänglig och testas på tre plattformar: Linux, Windows, MacOS. Du kan ladda ner installationsprogrammet för det operativsystem du är intresserad av från av vår webbplatsFör Linux-användare finns det ett alternativ att installera snap-paketVi hoppas verkligen att vi snart kommer till Microsoft Store och App Store (Men är det nödvändigt? Vad tycker du?).

Experimentellt scenario

Vi valde följande standardscenario som testobjekt:

• logga in: användare - admin, lösenord - lösenord
• låt oss lägga till en ny post
• Låt oss kontrollera att posten lades till korrekt

Vi kommer att testa på https://testmace-quick-start.herokuapp.com/Detta är normalt json-server, vilket är perfekt för att testa sådana applikationer. Vi har bara lagt till tokenauktorisering till alla json-server-rutter och skapat en inloggningsmetod för att få denna token. Vi kommer att gå framåt gradvis och gradvis förbättra vårt projekt.

Skapa ett projekt och försöka skapa en entitet utan auktorisering

Först, låt oss skapa ett nytt projekt (Fil->Nytt projektOm du kör programmet för första gången öppnas det nya projektet automatiskt. Låt oss först försöka göra en begäran om att skapa en ny post (plötsligt är det möjligt att skapa poster utan auktorisering). Välj alternativen i snabbmenyn för noden Projekt. Lägg till nod -> RequestStepVi ställer in nodnamnet till skapa-inläggSom ett resultat skapas en ny nod i trädet och en flik för noden öppnas. Låt oss ställa in följande frågeparametrar:

• Förfrågningstyp: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Begärantext: json med värde {"title": "New testmace quick start post"}
  Om du gjorde allt korrekt kommer gränssnittet att se ut så här:

Men om vi försöker utföra begäran kommer servern att returnera en 401-kod och utan auktorisering har vi ingen chans på den här servern. Tja, det är att vänta).

Lägga till en auktoriseringsbegäran

Som redan nämnts har vi en POST-slutpunkt /login, som accepterar en json av följande typ som en förfrågningstext: {"username": "<username>", "password": "<password>"}var username и password (återigen, från inledningen ovan) har betydelser admin и password respektive. Som svar returnerar denna slutpunkt json av formen {"token": "<token>"}Låt oss använda det för auktorisering. Låt oss skapa RequestStep nod med namn logga in, kommer att agera som en förfader Projekt nod. Använd dra-och-släpp för att flytta noden högre upp i trädet än noden skapa-inläggLåt oss ställa in följande parametrar för den nyligen skapade frågan:

• Förfrågningstyp: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Begärantext: json med värde {"username": "admin", "password": "password"}

Låt oss köra begäran och hämta den tvåhundrade koden med token i svaret. Något i stil med detta:

Refactoring: Ta bort domändubbletter

Frågorna är ännu inte länkade till ett enda scenario. Men detta är inte den enda nackdelen. Om du tittar noga kan du se att åtminstone domänen är duplicerad i båda frågorna. Inte bra. Det är hög tid att omstrukturera denna del av framtidsscenariot, och variabler kommer att hjälpa oss med detta.

I en första approximation spelar variabler samma roll som i andra liknande verktyg och programmeringsspråk – de eliminerar dubbelarbete, ökar läsbarheten etc. Du kan läsa mer om variabler i vår dokumentationI det här fallet behöver vi användarvariabler.

Låt oss definiera en variabel på projektnodnivå domain med mening https://testmace-quick-start.herokuapp.com. För detta är det nödvändigt

• Öppna fliken med den här noden och klicka på kalkylatorikonen i det övre högra hörnet
• Klicka på + LÄGG TILL VARIABEL
• Ange variabelnamnet och värdet
  I vårt fall kommer dialogrutan med den tillagda variabeln att se ut så här:

OK. Tack vare arv kan vi nu använda den här variabeln i ättlingar på vilken kapslingsnivå som helst. I vårt fall är dessa noder logga in и skapa-inläggFör att kunna använda en variabel i ett textfält måste du skriva ${<variable_name>}Till exempel konverteras URL:en för inloggning till ${domain}/loginrespektive för skapa-inlägg nodens URL kommer att se ut så här ${domain}/posts.

Så, enligt DRY-principen, förbättrade vi manuset lite.

Spara token till en variabel

Eftersom vi pratar om variabler, låt oss utveckla detta ämne lite. För närvarande, vid en lyckad inloggning, får vi en auktoriseringstoken från servern, som vi behöver i efterföljande förfrågningar. Låt oss spara denna token i en variabel. Eftersom variabelns värde kommer att bestämmas under körningen av skriptet, kommer vi att använda en speciell mekanism för detta — dynamiska variabler.

Först gör vi en inloggningsförfrågan. I fliken Parsad svaret, håll muspekaren över token och välj objektet i snabbmenyn (som anropas antingen genom att högerklicka eller genom att klicka på knappen ...). Tilldela till variabelEn dialogruta visas med följande fält:

• Bana - vilken del av svaret som tas (i vårt fall är det body.token)
• Nuvarande värde - vilket värde som ligger längs vägen (i vårt fall är detta symbolvärdet)
• Variabelnamn — namnet på variabeln där Nuvarande värde kommer att räddas. I vårt fall kommer det att vara token
• Nod — i vilken av förfäderna variabeln kommer att skapas VariabelnamnLåt oss välja Projekt

Den färdiga dialogrutan ser ut så här:

Nu, varje gång noden exekveras, logga in dynamisk variabel token kommer att uppdateras med det nya värdet från svaret. Och denna variabel kommer att lagras i Projekt nod och kommer att vara tillgänglig för ättlingar genom arv.

För att komma åt dynamiska variabler måste du använda inbyggd variabel $dynamicVarFör att till exempel komma åt en sparad token måste du anropa ${$dynamicVar.token}.

Vi skickar auktoriseringstoken till förfrågningar

I föregående steg fick vi en auktoriseringstoken och allt vi behöver göra är att lägga till en header. Authorization med mening Bearer <tokenValue> i alla förfrågningar som kräver auktorisering, inklusive skapa-inläggDet finns flera sätt att göra detta:

1. Kopiera token manuellt och lägg till auktoriseringsrubriken till de frågor du är intresserad av. Den här metoden fungerar, men dess användning är begränsad till frågor av typen "skapa och kasta bort". Den är inte lämplig för flera exekveringar av scenarier.
2. Använd funktionaliteten tillstånd.
3. Använd standardrubriker

Att använda den andra metoden verkar självklart, men i samband med den här artikeln är den här metoden… ointressant. Ja, egentligen: plus-minus-auktoriseringsmekanismen är bekant för dig från andra verktyg (även om vi har saker som arv av behörigheter) och det är osannolikt att det väcker några frågor.

Standardrubriker är en annan sak! Kort sagt är standardrubriker HTTP-rubriker som ärvs från förfäder och som läggs till i begäran som standard om de inte uttryckligen inaktiveras. Med hjälp av den här funktionen kan du till exempel implementera anpassad auktorisering eller helt enkelt bli av med dubbletter i scenarier. Låt oss tillämpa den här funktionen för att kasta en token i rubriker.

Tidigare hade vi förutseendet att spara token i en dynamisk variabel $dynamicVar.token på projektnodnivå. Följande återstår att göra:

1. Definiera standardtitel Authorization med mening Bearer ${$dynamicVar.token} på Projektnodnivå. För att göra detta, öppna en dialogruta med standardrubriker i Projektnodgränssnittet (knapp Headers i det övre högra hörnet) och lägg till lämplig titel. Dialogrutan med de ifyllda värdena kommer att se ut så här:
   
2. Inaktivera den här rubriken från inloggningsförfrågan. Detta är förståeligt: vid inloggningstillfället har vi ännu ingen token och vi kommer att installera den med denna begäran. Därför, i gränssnittet för inloggningsförfrågan i fliken Headers i området Ärvde Låt oss avmarkera rubriken Auktorisering.

Det var allt. Nu kommer auktoriseringsrubriken att läggas till alla förfrågningar som är underordnade till Projekt-noden, förutom inloggningsnoden. Det visar sig att vi i det här skedet redan har ett skript klart och allt vi behöver göra är att köra det. Du kan köra skriptet genom att välja Körning i snabbmenyn för Projekt-noden.

Kontrollerar att inlägget skapades korrekt

Vid det här laget kan vårt skript logga in och skapa ett inlägg med hjälp av en auktoriseringstoken. Vi måste dock se till att det nyskapade inlägget har rätt namn. Så i huvudsak återstår bara att göra följande:

• Skicka en begäran om att få ett inlägg via id,
• Kontrollera att namnet som tas emot från servern matchar namnet som skickades när inlägget skapades

Låt oss titta på det första steget. Eftersom id-värdet bestäms under skriptkörningen är det nödvändigt att skapa en dynamisk variabel (låt oss kalla den postId) från noden skapa-inlägg på projektnodnivå. Vi vet redan hur man gör detta, se bara avsnittet Spara token till en variabelAllt som återstår är att skapa en begäran om att få ett inlägg med detta id. För att göra detta, skapa ett RequestStep. få-inlägg med följande parametrar:

• Förfrågningstyp: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

För att genomföra det andra steget behöver vi bekanta oss med påstående nod. En assertionnod är en nod som låter dig skriva kontroller för specifika frågor. Varje assertionnod kan innehålla flera assertioner (kontroller). Du kan läsa mer om alla typer av assertioner i vår dokumentation. Vi kommer använda Compare påstående med operator equalDet finns flera sätt att skapa påståenden:

1. Lång. Skapa manuellt en Assertion-nod från kontextmenyn för RequestStep-noden. Lägg till intresseanmälan och fyll i fälten i den skapade Assertion-noden.
2. Snabb: Skapa en Assertion-nod tillsammans med en assertion från RequestStep-nodsvaret med hjälp av kontextmenyn.

Låt oss använda den andra metoden. Så här kommer det att se ut i vårt fall.

För er som inte förstår, här är vad som händer:

1. Gör en fråga i noden få-inlägg
2. I fliken Parsad svara på samtalet via snabbmenyn och välj Skapa påstående -> Jämför -> Lika

Grattis, vi har skapat det första testet! Enkelt, eller hur? Nu kan du köra skriptet helt och njuta av resultatet. Allt som återstår är att omstrukturera det lite och flytta ut det. title till en separat variabel. Men vi lämnar det som läxa åt dig)

Slutsats

I den här guiden har vi skapat ett komplett scenario och även granskat några av funktionerna i vår produkt. Naturligtvis använde vi inte all funktionalitet och i följande artiklar kommer vi att göra en detaljerad granskning av TestMaces möjligheter. Håll utkik!

P.S. För er som är för lata för att upprepa alla steg har vi vänligen gjort en video förvaret med projektet från artikeln. Du kan öppna den med Fil -> Öppet projekt och välj Projekt-mappen.

Källa: will.com