Hej alla. Vi kommer sakta fram ur skuggorna och fortsätter serien med artiklar om vår produkt. Efter recensionsartikel fick vi mycket feedback (mestadels positiv), förslag och felrapporter. Idag ska vi visa i aktion och du kommer att kunna uppskatta några av funktionerna i vår applikation. För en mer komplett fördjupning rekommenderar jag att du hänvisar till vår dokumentation på . Låt oss gå!
Installation
Låt oss börja med banaliteten. Applikationen är tillgänglig och faktiskt testad på tre plattformar - Linux, Windows, MacOS. Du kan ladda ner installationsprogrammet för det operativsystem du är intresserad av från . För Linux-användare är det möjligt att installera . Vi hoppas verkligen att Microsoft Store och App Store snart tar sig an det (Är det nödvändigt? Vad tycker du?).
Experimentellt scenario
Vi valde följande standardscenario som vårt testämne:
- Inloggning: användare - admin, lösenord - lösenord
- lägga till en ny post
- Låt oss kontrollera att posten har lagts till korrekt
Vi ska testa på . Det här är normalt , perfekt för att testa sådana applikationer. Vi har precis lagt till auktorisering via token till alla json-serverrutter och skapat en inloggningsmetod för att ta emot denna token. Vi kommer att gå successivt och gradvis förbättra vårt projekt.
Skapar ett projekt och försöker skapa en enhet utan tillstånd
Låt oss först skapa ett nytt projekt (Fil->Nytt projekt). Om du startar applikationen för första gången öppnas ett nytt projekt automatiskt. Låt oss först försöka göra en begäran om att skapa en ny post (i fall att skapa poster är tillgängligt utan tillstånd). Välj objekt från projektnodens snabbmeny Lägg till nod -> RequestStep. Ställ in nodnamnet till skapa-inlägg. Som ett resultat kommer en ny nod att skapas i trädet och en flik för denna nod öppnas. Låt oss ställa in följande begäran parametrar:
- Typ av begäran: POST
- url:
- Begäran text: 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 uppfylla begäran kommer servern att returnera en 401-kod och utan auktorisering får vi inget på denna server. Tja, i allmänhet, som förväntat).
Lägger till en auktoriseringsbegäran
Som redan sagt har vi en POST-slutpunkt /login, som tar json som en begärandetext i formuläret: {"username": "<username>", "password": "<password>"}var username и password (igen, från det inledande stycket ovan) har betydelser admin и password respektive. Som svar returnerar denna slutpunkt json like {"token": "<token>"}. Vi kommer att använda den för auktorisering. Låt oss skapa RequestStep nod med namn logga in, kommer att fungera som en förfader Projekt nod Använd dra-och-släpp, flytta en given nod i trädet högre än noden skapa-inlägg. Låt oss ställa in följande parametrar för den nyskapade begäran:
- Typ av begäran: POST
- url:
- Begäran text: json med värde
{"username": "admin", "password": "password"}
Låt oss köra begäran och ta emot den tvåhundrade koden med token i svaret. Något som det här:
Refaktorering: tar bort domänduplicering
Än så länge är förfrågningarna inte länkade till ett enda skript. Men detta är inte den enda nackdelen. Om du tittar noga kommer du att märka att åtminstone domänen är duplicerad i båda förfrågningarna. Inte bra. Det är dags att omstrukturera den här delen av det framtida skriptet, och variabler kommer att hjälpa oss med detta.
Till en första approximation tjänar variabler samma roll som i andra liknande verktyg och programmeringsspråk - eliminerar duplicering, ökar läsbarheten, etc. Du kan läsa mer om variabler i . I det här fallet kommer vi att behöva 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 denna nod och klicka på kalkylatorikonen uppe till höger
- Klicka på + LÄGG TILL VARIABELL
- Ange variabelnamn och värde
I vårt fall kommer dialogen med den tillagda variabeln att se ut så här:
OK. Nu, på grund av nedärvning, kan vi använda den här variabeln i ättlingar av vilken häckningsnivå som helst. I vårt fall är dessa noder logga in и skapa-inlägg. För att kunna använda en variabel i ett textfält måste du skriva ${<variable_name>}. Till exempel konverteras inloggningsadressen till ${domain}/login, respektive för skapa-inlägg nod-url kommer att se ut ${domain}/posts.
Med ledning av DRY-principen har vi alltså förbättrat scenariot något.
Spara token till en variabel
Eftersom vi pratar om variabler, låt oss utöka detta ämne lite. För tillfället, vid lyckad inloggning, får vi från servern en auktoriseringstoken, som vi kommer att behöva i efterföljande förfrågningar. Låt oss spara denna token i en variabel. Därför att värdet på variabeln kommer att bestämmas under skriptkörning, vi använder en speciell mekanism för detta - .
Låt oss först göra en inloggningsförfrågan. I fliken Analyserad svara, flytta markören över token och i snabbmenyn (som kallas antingen med höger musknapp eller genom att klicka på knappen ...) välj objektet Tilldela till variabel. En 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 ligger längs vägen (i vårt fall är detta symbolvärdet)
- Variabelnamn — Namnet på variabeln where Nuvarande värde kommer att bevaras. I vårt fall kommer det att bli det
token - Nod — i vilken av förfäderna variabeln kommer att skapas Variabelnamn. Lå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, tack vare arv, kommer den att vara tillgänglig för ättlingar.
För att komma åt dynamiska variabler måste du använda $dynamicVar. Till exempel, för att komma åt en lagrad token måste du ringa ${$dynamicVar.token}.
Vi skickar auktoriseringstoken till förfrågningar
I de föregående stegen fick vi auktoriseringstoken och allt vi behöver göra är att lägga till en rubrik Authorization med mening Bearer <tokenValue> i alla förfrågningar som kräver auktorisation, inklusive skapa-inlägg. Det finns flera sätt att göra detta:
- Kopiera token manuellt och lägg till en auktoriseringsrubrik till intresseförfrågningarna. Metoden fungerar, men dess användning är endast begränsad till förfrågningar av typen "gjorda och slängda". Inte lämplig för upprepad körning av skript
- Använd funktionen .
- Använd
Att använda den andra metoden verkar självklart, men i sammanhanget av denna artikel är detta tillvägagångssätt... ointressant. Tja, verkligen: auktoriseringsmekanismen plus minus är bekant för dig från andra verktyg (även om vi har saker som ) och kommer sannolikt inte att väcka frågor.
En annan sak är standardhuvudena! I ett nötskal är standardrubriker ärvda HTTP-rubriker som läggs till förfrågan som standard om de inte uttryckligen inaktiverats. Med denna funktionalitet kan du till exempel implementera anpassad auktorisering eller helt enkelt bli av med duplicering i skript. Låt oss använda den här funktionen för att skicka en token i rubrikerna.
Tidigare har vi försiktigt sparat token till en dynamisk variabel $dynamicVar.token på projektnodnivå. Allt som återstår är att göra följande:
- Definiera standardtitel
Authorizationmed meningBearer ${$dynamicVar.token}på projektnodnivå. För att göra detta måste du i nodens projektgränssnitt öppna en dialogruta med standardrubriker (knapp Headers i det övre högra hörnet) och lägg till en motsvarande titel. Dialogrutan med de ifyllda värdena kommer att se ut så här:
- Inaktivera denna rubrik från inloggningsförfrågan. Detta är förståeligt: vid tidpunkten för inloggningen har vi ännu ingen token och vi kommer att installera den med denna begäran. Därför, i inloggningsgränssnittet för begäran på fliken Headers i området Ärvde avmarkera auktoriseringshuvudet.
Det är allt. Nu kommer auktoriseringshuvudet att läggas till för alla förfrågningar som är underordnade projektnoden, förutom inloggningsnoden. Det visar sig att vi i det här skedet redan har ett manus klart och allt vi behöver göra är att lansera det. Du kan köra skriptet genom att välja Körning i projektnodens snabbmeny.
Kontrollera om inlägget skapades korrekt
I det här skedet kan vårt skript logga in och, med hjälp av en auktoriseringstoken, skapa ett inlägg. Vi måste dock se till att det nyskapade inlägget har rätt namn. Det vill säga, i huvudsak är allt som återstår att göra följande:
- Skicka en begäran om att få ett inlägg med id,
- Kontrollera att namnet från servern stämmer överens med 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örning måste du skapa en dynamisk variabel (låt oss kalla det postId) från noden skapa-inlägg på projektnodnivå. Vi vet redan hur man gör detta, se bara avsnittet Spara token till en variabel. Allt som återstår är att skapa en begäran om att få ett inlägg med detta id. För att göra detta, låt oss skapa ett RequestStep få inlägg med följande parametrar:
- Typ av begäran: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
För att genomföra det andra steget måste vi bekanta oss med Knut. En påståendenod är en nod som låter dig skriva checkar för specifika förfrågningar. Varje påståendenod kan innehålla flera påståenden (kontroller). Du kan läsa mer om alla typer av påståenden från vår . Vi kommer använda Compare påstående med operatören equal. Det finns flera sätt att skapa påståenden:
- Lång. Skapa en Assertion-nod manuellt från snabbmenyn i RequestStep-noden. I den skapade påståendenoden lägger du till intresseanmälan och fyller i fälten.
- Snabb. Skapa en påståendenod tillsammans med ett påstående från RequestStep-nodsvaret med hjälp av snabbmenyn
Låt oss använda den andra metoden. Så här kommer det att se ut för vårt fall.
För de som inte förstår, här är vad som händer:
- Gör en begäran i noden få inlägg
- I fliken Analyserad svara, ring upp snabbmenyn och välj Skapa påstående -> Jämför -> Lika
Grattis, vi har skapat vårt första test! Enkelt, eller hur? Nu kan du köra skriptet helt och hållet och njuta av resultatet. Allt som återstår är att refaktorera den lite och ta ut den title till en separat variabel. Men vi lämnar detta till dig som läxa)
Slutsats
I den här guiden skapade vi ett fullfjädrat scenario och granskade samtidigt några av funktionerna i vår produkt. Naturligtvis använde vi inte all funktionalitet och i följande artiklar kommer vi att ge en detaljerad översikt över funktionerna hos TestMace. Håll ögonen öppna!
PS För de som är för lata för att återge alla steg har vi snällt spelat in med projektet från artikeln. Du kan öppna den med Fil -> Öppet projekt och välj mappen Projekt.
Källa: will.com