Hallo iedereen. We komen langzaam weer in de schijnwerpers en gaan verder met onze reeks artikelen over ons product. Na de vorige de introductie hebben we veel feedback ontvangen (voornamelijk positief), suggesties en bugrapporten. Vandaag laten we je TestMace zien hoe het werkt, zodat je enkele functies van onze applicatie kunt waarderen. Voor een vollediger beeld raad ik aan om onze documentatie te raadplegen op http://docs-ru.testmace.com. Laten we beginnen!

Installatie

We starten met het voor de hand liggende. De applicatie is beschikbaar en kan daadwerkelijk getest worden op drie platforms: Linux, Windows, MacOS. Je kunt de installer voor het gewenste OS downloaden vanaf onze website. Voor Linux-gebruikers is er de optie om een snap packagete installeren. We hopen echt dat we binnenkort ook Microsoft Store en App Store kunnen aanpakken (maar is dat nodig? Wat denken jullie?).

Testscenario

Als testscenario hebben we het volgende standaardscenario gekozen:

• we loggen in: gebruiker — admin, wachtwoord — password
• we voegen een nieuwe record toe
• we controleren of de record correct is toegevoegd

We gaan testen op https://testmace-quick-start.herokuapp.com/. Dit is een gewone json-server, perfect geschikt voor het testen van dergelijke applicaties. We hebben alleen token-authenticatie aan alle routes van de json-server toegevoegd en een login-methode gemaakt om deze token te verkrijgen. We zullen stap voor stap vooruitgaan en ons project geleidelijk verbeteren.

Project aanmaken en proberen om een entiteit zonder authenticatie te creëren

Laten we beginnen met het aanmaken van een nieuw project (Bestand->Nieuw project). Als je de applicatie voor het eerst start, wordt het nieuwe project automatisch geopend. Laten we eerst proberen een verzoek te doen om een nieuwe record aan te maken (misschien is het creëren van records zonder authenticatie mogelijk). Kies in het contextmenu van de Project-knoop de opties Knoop toevoegen -> RequestStep. Als naam voor de knoop geven we create-postop. Hierdoor wordt er een nieuwe knoop in de boom aangemaakt en wordt het tabblad van die knoop geopend. Stel de volgende parameters voor het verzoek in:

• Type verzoek: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Body van het verzoek: json met de waarde {"title": "New testmace quick start post"}
  Als je alles goed hebt gedaan, zou de interface er als volgt uit moeten zien:

Maar als we het verzoek proberen uit te voeren, zal de server een 401-code retourneren en zonder authenticatie is er niets mogelijk op deze server. Nou, dat was wel te verwachten).

Voeg een verzoek voor authenticatie toe

Zoals eerder vermeld, hebben we een POST endpoint /login, dat een JSON van het type als body van het verzoek accepteert: {"username": "", "password": ""}, waar username en password (opnieuw, uit de bovenstaande inleiding) hebben waarden admin en password daarom. Dit endpoint retourneert een JSON-structuur {"token": ""}. We zullen het gebruiken voor authenticatie. Laten we RequestStep een knooppunt met de naam login, met als ouder Project knooppunt. Gebruik drag-and-drop om dit knooppunt hoger in de boom te plaatsen dan knooppunt create-post. Laten we de volgende parameters aan de nieuw gemaakte aanvraag toekennen:

• Type verzoek: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Body van het verzoek: json met de waarde {"username": "admin", "password": "password"}

Voer de aanvraag uit en ontvang een tweehonderd code met een token in de reactie. Zoiets:

Refactoren: duplicatie van het domein verwijderen

Momenteel zijn de aanvragen niet verbonden in een enkel scenario. Maar dit is niet de enige tekortkoming. Als je beter kijkt, zie je dat het domein in beide aanvragen minimaal wordt gedupliceerd. Niet goed. Het is tijd om dit deel van het toekomstige scenario te refactoren en variabelen zullen ons daarbij helpen.

In eerste instantie vervullen variabelen dezelfde rol als in andere vergelijkbare tools en programmeertalen - het vermijden van duplicatie, het verhogen van de leesbaarheid, enzovoorts. Meer over variabelen is te lezen in onze documentatie. In dit geval hebben we gebruikersvariabelen nodig.

Laten we op het niveau van het Project knooppunt een variabele definiëren domein met de waarde https://testmace-quick-start.herokuapp.com. Hiervoor is het nodig

• Om het tabblad van dit knooppunt te openen en op het rekenmachine-icoon rechtsboven te klikken
• Klik op + ADD VARIABLE
• Voer de naam en waarde van de variabele in
  In ons geval ziet de dialoog met de toegevoegde variabele er als volgt uit:

OK. Dankzij overerving kunnen we deze variabele gebruiken in afgeleiden knooppunten van elke diepte. In ons geval betreft dit de knooppunten login en create-post. Om de variabele in het tekstveld te gebruiken, moet je schrijven ${}. Bijvoorbeeld, de URL voor aanmelding verandert in ${domain}/login, dus voor create-post knooppunt zal de URL er als volgt uitzien ${domain}/posts.

Op deze manier hebben we, volgens het DRY-principe, het scenario iets verbeterd.

We slaan de token op in een variabele

Aangezien we het over variabelen hebben, laten we dit onderwerp verder ontwikkelen. Momenteel ontvangen we bij een succesvolle aanmelding een autorisatietoken van de server, dat we nodig hebben voor toekomstige aanvragen. Laten we deze token in een variabele opslaan. Aangezien de waarde van de variabele tijdens de uitvoering van het scenario wordt bepaald, gebruiken we hiervoor een speciaal mechanisme - dynamische variabelen.

Laten we beginnen met het uitvoeren van de aanmelding. In het tabblad Parsed Om een antwoord te krijgen, plaatst u de cursor op de token en kiest u in het contextmenu (dat wordt geopend met de rechtermuisknop of door op de knop … te drukken) de optie Toewijzen aan variabele. Er verschijnt een dialoogvenster met de volgende velden:

• Pad — welk deel van het antwoord wordt genomen (in ons geval is dat body.token)
• Huidige waarde — welke waarde ligt er op het pad Pad (in ons geval is dat de waarde van de token)
• Variabelenaam — de naam van de variabele waarin Huidige waarde wordt opgeslagen. In ons geval zal dit zijn token
• Node — in welke voorouder de variabele zal worden aangemaakt Variabelenaam. Laten we Project kiezen

Het ingevulde dialoogvenster ziet er als volgt uit:

Nu, bij elke uitvoering van de node login zal de dynamische variabele token worden bijgewerkt met de nieuwe waarde uit het antwoord. En deze variabele zal worden opgeslagen in Project de node en dankzij overerving beschikbaar zijn voor de nakomelingen.

Om toegang te krijgen tot dynamische variabelen, moet u gebruikmaken van de ingebouwde variabele $dynamicVar. Bijvoorbeeld, om bij de opgeslagen token te komen, moet u aanroepen ${$dynamicVar.token}.

We sturen de autorisatietoken door in verzoeken

In de vorige stappen hebben we de autorisatietoken gekregen en we hoeven alleen maar de header toe te voegen Authorization met de waarde Bearer aan alle verzoeken die autorisatie vereisen, inclusief in create-post. Hiervoor zijn er verschillende manieren:

1. Handmatig de token kopiëren en de autorisatieheader toevoegen aan de gewenste verzoeken. Deze methode werkt, maar is beperkt tot verzoeken van het type "gedaan en weggegooid". Niet geschikt voor herhaaldelijke uitvoering van scenario's.
2. Gebruik maken van de functionaliteit van autorisatie.
3. Gebruik standaard headers

Het gebruik van de tweede methode lijkt voor de hand liggend, maar in de context van dit artikel is deze benadering… niet interessant. Immers: het mechanisme van autorisatie is min of meer bekend bij u uit andere tools (ook al hebben we dingen zoals erfenis van autorisaties) en zal waarschijnlijk geen vragen oproepen.

Wat betreft de standaard headers! In een paar woorden, de standaard headers zijn geërfde HTTP-headers die standaard aan het verzoek worden toegevoegd, tenzij ze expliciet worden uitgeschakeld. Met deze functionaliteit kunt u bijvoorbeeld een aangepaste autorisatie implementeren of gewoon duplicatie in scenario's vermijden. We zullen deze functie toepassen voor het doorgeven van de token in de headers.

Eerder hebben we het token opgeslagen in een dynamische variabele $dynamicVar.token op het niveau van de Project-knoop. We moeten nu het volgende doen:

1. Bepaal de standaardheader Authorization met de waarde Bearer ${$dynamicVar.token} op het niveau van de Project-knoop. Hiervoor moet in de interface van de Project-knoop het dialoogvenster met de standaardheaders worden geopend (knop Headers in de rechterbovenhoek) en de juiste header worden toegevoegd. Het dialoogvenster met ingevulde waarden zal er als volgt uitzien:
   
2. Zet deze header uit bij het loginverzoek. Dit is logisch: op het moment van inloggen hebben we nog geen token en met dit verzoek willen we het juist instellen. Daarom moeten we in de interface van het loginverzoek onder het tabblad Headers in het gebied Inherited de vink in het Authorization-header verwijderen.

Dat is alles. Nu zal de autorisatieheader aan alle verzoeken worden toegevoegd die afstammelingen zijn van de Project-knoop, behalve de login-knoop. Het lijkt erop dat we op dit moment al een script hebben en we hoeven het alleen maar uit te voeren. Het script kan worden uitgevoerd door de optie Run in het contextmenu van de Project-knoop te selecteren.

We controleren of de post correct is aangemaakt

Op dit moment kan ons script inloggen en, gebruikmakend van de autorisatietoken, een post aanmaken. We moeten er echter zeker van zijn dat de nieuw aangemaakte post de juiste naam heeft. Dat wil zeggen, in feite moeten we het volgende doen:

• Stuur een verzoek om de post op te halen op basis van id,
• Controleer of de naam die van de server komt overeenkomt met de naam die bij het aanmaken van de post is doorgegeven

Laten we de eerste stap bekijken. Aangezien de waarde van id tijdens de uitvoering van het script wordt bepaald, moeten we een dynamische variabele aanmaken (laten we deze noemen postId) vanuit de knoop create-post op het niveau van de Project-knoop. Hoe we dat doen weten we al, het is voldoende om naar de sectie We slaan de token op in een variabelete verwijzen. We moeten alleen een verzoek maken om de post op te halen op basis van deze id. Daarom maken we een RequestStep get-post met de volgende parameters:

• Type verzoek: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Voor de uitvoering van de tweede stap moeten we kennismaken met Assertion de knoop. De Assertion-knoop — dat is een knoop die het mogelijk maakt om controles voor bepaalde verzoeken te schrijven. Elke Assertion-knoop kan meerdere beweringen (controles) bevatten. Meer over de verschillende soorten beweringen kun je lezen in onze de documentatie. We zullen gebruik maken van Compare assertion met de operator equal. Er zijn verschillende manieren om beweringen aan te maken:

1. Langdurig. Handmatig een Assertion-knooppunt maken via het contextmenu van de RequestStep-knoop. Voeg de gewenste assertion toe in het gemaakte Assertion-knooppunt en vul de velden in.
2. Snel. Maak een Assertion-knooppunt samen met de assertion uit het antwoord van de RequestStep-knoop via het contextmenu.

Laten we de tweede methode gebruiken. Zo zal het eruitzien voor onze casus.

Voor degenen die het niet begrepen hebben, hier gebeurt het volgende:

1. Doe een verzoek in het knooppunt get-post
2. In het tabblad Parsed antwoord, roep het contextmenu op en kies Create assertion -> Compare -> Equal

Gefeliciteerd, we hebben de eerste test gemaakt! Vrij eenvoudig, toch? Nu kunt u het script in zijn geheel uitvoeren en genieten van het resultaat. We moeten nog een klein beetje refactoren en het title in een aparte variabele onderbrengen. Maar we laten dit als huiswerk aan u over :)

Conclusie

In deze handleiding hebben we een volledig script gemaakt en daarbij enkele functies van ons product besproken. Uiteraard hebben we niet alle functionaliteit gebruikt en in de volgende artikelen zullen we een gedetailleerd overzicht geven van de mogelijkheden van TestMace. Blijf op de hoogte van updates!

P.S. Voor degenen die het te veel gedoe vinden om alle stappen te reproduceren, hebben we vriendelijk repository met het project uit het artikel. U kunt het openen met Bestand -> Open project en kies de map Project.

Bron: habr.com