Hej alla. Vi börjar långsamt komma fram i ljuset och fortsätter vår serie av artiklar om vår produkt. Efter den föregående översiktsartikeln fick vi många återkopplingar (övervägande positiva), förslag och buggrapporter. Idag kommer vi att visa TestMace det i praktiken och ni kommer att kunna utvärdera några funktioner i vår applikation. För en mer komplett upplevelse rekommenderar jag att ni besöker vår dokumentation på adressen http://docs-ru.testmace.com. Så, låt oss börja!

Installation

Vi börjar med det uppenbara. Applikationen är tillgänglig och kan verkligen testas på tre plattformar – Linux, Windows, MacOS. Ni kan ladda ner installationsprogrammet för den intressanta OS från vår website. För Linux-användare finns det möjlighet att installera snap-paketet. Vi hoppas verkligen att vi snart också får till Microsoft Store och App Store (behövs det? Vad tycker ni?).

Testscenariot

Vi har valt följande standardscenario som testobjekt:

• logga in: användare – admin, lösenord – password
• lägga till en ny post
• kontrollera korrektheten i tilläggningen av posten

Vi kommer att testa på https://testmace-quick-start.herokuapp.com/. Det är en vanlig json-server, som passar perfekt för att testa sådana applikationer. Vi har bara lagt till tokenbaserad autentisering på alla rutter av json-server och skapat en login-metod för att få den nämnda token. Vi kommer att gå framåt steg för steg och gradvis förbättra vårt projekt.

Skapande av projekt och försök att skapa en entitet utan autentisering

Först skapar vi ett nytt projekt (Arkiv->Nytt projekt). Om ni kör applikationen för första gången öppnas ett nytt projekt automatiskt. Vi börjar med att försöka göra en begäran om att skapa en ny post (kanske skapandet av poster är tillgängligt utan autentisering). Välj i kontextmenyn Project noden som heter Lägg till nod -> BegäranSteg. Ange följande namn för noden: create-post. Resultatet blir att en ny nod skapas i trädet och fliken för denna nod öppnas. Ställ in följande parameterar för begäran:

• Typ av begäran: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Begärans kropp: json med värdet {"title": "New testmace quick start post"}
  Om ni har gjort allt rätt kommer gränssnittet att se ut som följande:

Men om vi försöker genomföra begäran kommer servern att returnera kod 401 och utan autentisering är ingenting möjligt på denna server. Ja, det är helt förväntat).

Lägg till begäran för autentisering

Som redan nämnts har vi en POST endpoint /login, som tar emot json av följande typ som begärans kropp: {"username": "", "password": ""}, där username och password (återigen, från den inledande ovan) har betydelse admin och password därmed. I svaret returnerar denna endpoint json av typen {"token": ""}. Vi kommer att använda det för autentisering. Låt oss skapa BegäranSteg en nod med namnet login, där föräldern kommer att vara Projekt noden. Med hjälp av drag-and-drop flyttar du denna nod i trädet högre än noden create-post. Vi kommer att ställa in följande parametrar för den nyligen skapade förfrågan:

• Typ av begäran: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Begärans kropp: json med värdet {"username": "admin", "password": "password"}

Vi utför förfrågan och får en tvåhundrad elva kod med token i svaret. Så här:

Refaktorering: tar bort domänerna

Tills dess är förfrågningarna inte kopplade i ett enda scenario. Men det är inte den enda bristen. Om du tittar noga kan du märka att åtminstone domänen dupliceras i båda förfrågningarna. Inte bra. Det är dags att refaktorera denna del av det framtida scenariot och variabler kommer att hjälpa oss med detta.

I första hand utför variabler samma roll som i andra liknande verktyg och programmeringsspråk — eliminera duplicering, öka läsbarheten, osv. Mer om variabler kan läsas i vår dokumentation. I detta fall kommer vi att behöva användardefinierade variabler.

Definiera en variabel på projektets nivå domain med värdet https://testmace-quick-start.herokuapp.com. För detta behöver du

• öppna fliken för denna nod och klicka på kalkylatorikonen till höger uppe
• klicka på + ADD VARIABLE
• ange namn och värde för variabeln
  I vårt fall kommer dialogen med den tillagda variabeln att se ut som följer:

OK. Nu kan vi, tack vare arv, använda denna variabel i avkommor på vilken nivå av inbäddning som helst. I vårt fall är det noder login och create-post. För att använda variabeln i textrutan måste du skriva ${}. Till exempel, url för inloggning omvandlas till ${domain}/login, och för create-post noden kommer url att se ut som ${domain}/posts.

Således, med principen DRY i åtanke, har vi något förbättrat scenariot.

Spara token i en variabel

Eftersom vi pratar om variabler, låt oss utveckla detta ämne något. Just nu får vi vid en lyckad inloggning en autentiseringstoken från servern, som vi kommer att behöva i efterföljande förfrågningar. Låt oss spara denna token i en variabel. Eftersom värdet på variabeln kommer att definieras under körning av scenariot, använder vi en speciell mekanism — dynamiska variabler.

För att börja, låt oss göra en inloggningsbegäran. I fliken Parsed svaret, hovra med muspekaren över token och välj punkten i kontextmenyn (som anropas antingen med höger musknapp eller genom att trycka på knappen …) Tilldela till variabel. En dialogruta kommer att dyka upp med följande fält:

• Path — vilken del av svaret som tas (i vårt fall är det body.token)
• Aktuellt värde — vilket värde som finns på sökvägen Path (i vårt fall är detta token-värdet)
• Variabelnamn — namnet på variabeln där Aktuellt värde det kommer att sparas. I vårt fall blir det token
• Node — i vilken av förfäderna variabeln kommer att skapas Variabelnamn. Låt oss välja Projekt

Fyllt dialog ser ut som följer:

Nu, vid varje körning av noden, login kommer den dynamiska variabeln token att uppdateras med det nya värdet från svaret. Och denna variabel kommer att lagras i Projekt noden och tack vare ärvandet vara tillgänglig för efterkommande.

För att referera till dynamiska variabler måste man använda inbyggd variabel $dynamicVar. Till exempel, för att nå det sparade tokenet bör du aktivera ${$dynamicVar.token}.

Vi skickar autentiseringstoken i begärningar

I tidigare steg fick vi autentiseringstoken och allt vi behöver göra är att lägga till en rubrik Authorization med värdet Bearer i alla begärningar som kräver autentisering, inklusive i create-post. Det finns flera sätt att göra detta:

1. Manuellt kopiera token och lägga till autentiseringrubriken i intressanta begärningar. Denna metod fungerar, men dess användning är begränsad till begärningar av typen "gjord och kastad". För flera körningar av scenarier är den inte lämplig.
2. Använda funktionaliteten för autentisering.
3. Använd standardrubriker

Användningen av den andra metoden verkar uppenbar, men i kontexten av denna artikel är en sådan ansats… ointressant. Egentligen: autentiseringsmekanismen är mer eller mindre bekant för er från andra verktyg (även om vi har saker som ärvande av autentiseringar) och kommer sannolikt inte att väcka några frågor.

En annan historia är standardrubriker! Kort sagt är standardrubrikerna de som ärvs från HTTP-rubrikerna och som läggs till begäran som standard om de inte uttryckligen stängs av. Med denna funktionalitet kan man till exempel implementera anpassad autentisering eller helt enkelt bli av med dubbletter i scenarier. Vi tillämpar denna funktion för att skicka en token i rubrikerna.

Tidigare har vi förutseende sparat token i en dynamisk variabel $dynamicVar.token på nivån av Project-noden. Återstår att göra följande:

1. Definiera standardrubriken Authorization med värdet Bearer ${$dynamicVar.token} på nivån av Project-noden. För detta ändamål måste du i Project-nodens gränssnitt öppna dialogen för standardrubriker (knappen Headers i det övre högra hörnet) och lägga till motsvarande rubrik. Dialogen med ifyllda värden kommer att se ut som följer:
   
2. Avaktivera denna rubrik från login-begäran. Det är uppenbart: vid inloggningen har vi ännu ingen token och genom denna begäran sätter vi just den. Därför, i gränssnittet för login-begäran, under fliken Headers i området Inherited tar vi bort markeringen från Authorization-rubriken.

Detta är allt. Nu kommer autentiseringsrubriken att läggas till i alla begärningar som är ättlingar till Project-noden, förutom login-noden. Det betyder att vi nu redan har ett klart manus och vi behöver bara köra det. Vi kan köra manuset genom att välja punkten Run i snabbmenyn för Project-noden.

Kontrollerar korrektheten av postskapandet

Vid detta stadium kan vårt manus logga in och, med hjälp av autentiseringstoken, skapa inlägg. Men vi måste se till att det nyss skapade inlägget har ett korrekt namn. Det vill säga, i grund och botten kvarstår följande:

• Skicka en begäran för att hämta inlägget efter id,
• Kontrollera att namnet som kommer från servern överensstämmer med namnet som skickades vid skapandet av inlägget

Låt oss titta på det första steget. Eftersom värdet på id bestäms under skriptets körning är det nödvändigt att skapa en dynamisk variabel (vi kallar den postId) från noden create-post på nivån av Project-noden. Så här gör vi det vet vi redan, det är tillräckligt att gå till avsnittet Spara token i en variabel. Återstår bara att skapa en begäran för att hämta inlägget med det angivna id:t. För detta ändamål ska vi skapa en RequestStep get-post med följande parametrar:

• Begärningstyp: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

För att genomföra det andra steget behöver vi bekanta oss med Assertion noden. Assertion-noden är en nod som gör det möjligt att skriva kontroller för specifika förfrågningar. Varje Assertion-nod kan innehålla flera påståenden (kontroller). Läs mer om alla typer av assertioner i vår dokumentationen. Vi kommer att använda Compare assertion med operatorn equal. Det finns flera sätt att skapa assertioner:

1. Långt. Skapa assertion-nod manuellt från kontextmenyn för RequestStep-noden. I den skapade Assertion-noden läggs det intressanta påståendet till och fälten fylls i.
2. Snabbt. Skapa assertion-nod tillsammans med påståendet från svaret av RequestStep-noden med hjälp av kontextmenyn.

Vi använder oss av det andra sättet. Så här kommer det att se ut för vårt fall.

För dem som inte förstod, så sker följande:

1. Gör en förfrågan i noden get-post
2. I fliken Parsed öppna kontextmenyn för svaret och välj Create assertion -> Compare -> Equal

Grattis, vi har skapat vårt första test! Enkelt, eller hur? Nu kan du köra scenariot helt och hållet och njuta av resultatet. Kvar är bara att refaktorera och flytta title till en enskild variabel. Men vi överlåter det till dig som en läxa)

Slutsats

I denna vägledning har vi skapat ett komplett scenario och dessutom gjort en översyn av några funktioner i vår produkt. Självklart utnyttjade vi inte all funktionalitet och i kommande artiklar kommer vi att göra en detaljerad översyn av TestMace:s möjligheter. Håll utkik efter uppdateringar!

P.S. För dem som inte orkar återskapa alla steg har vi vänligen delat arkiv med projektet från artikeln. Du kan öppna det med hjälp av Arkiv -> Open project och välja mappen Project.

Källa: habr.com