Hej alle sammen. Vi træder forsigtigt frem fra skyggerne og fortsætter serien af artikler om vores produkt. Efter den forrige den indledende artikel modtog vi mange anmeldelser (primært positive), forslag og fejlrapporter. I dag vil vi vise TestMace det i praksis, så I kan vurdere nogle af funktionerne i vores applikation. For en mere fuldendt oplevelse anbefaler vi at kigge i vores dokumentation på adressen http://docs-ru.testmace.com. Så lad os komme i gang!

Installation

Vi starter med det mest indlysende. Applikationen er tilgængelig og kan faktisk testes på tre platforme — Linux, Windows, MacOS. Du kan downloade installationsprogrammet til dit ønskede OS fra vores hjemmeside. For linux-brugere er der mulighed for installation af snap-pakken. Vi håber meget, at vi snart også når Microsoft Store og App Store (er det nødvendigt? Hvad tænker I?).

Testscenarie

Som testscenario har vi valgt følgende standardprocedure:

• log ind: bruger — admin, kodeord — password
• tilføje en ny post
• tjekke korrekt tilføjelse af posten

Vi vil teste på https://testmace-quick-start.herokuapp.com/. Det er en almindelig json-server, som fungerer glimrende til test af sådanne applikationer. Vi har kun tilføjet token-autentifikation til alle ruter i json-serveren og lavet en login-metode til at få dette token. Vi vil bevæge os fremad skridt for skridt og gradvist forbedre vores projekt.

Oprettelse af projekt og forsøg på at oprette en entitet uden autentifikation

Først opretter vi et nyt projekt (Fil->Nyt projekt). Hvis du starter applikationen for første gang, åbnes det nye projekt automatisk. Lad os først forsøge at sende en anmodning om at oprette en ny post (måske er det muligt at oprette poster uden autentifikation). Vælg punkterne i kontekstmenuen for Project-noden Tilføj node -> RequestStep. Som nodens navn angiver vi create-post. Resultatet er, at der oprettes en ny node i træet, og fanen for denne node åbnes. Vi angiver følgende parametre for anmodningen:

• Anmodningstype: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Anmodningens krop: json med værdien {"title": "New testmace quick start post"}
  Hvis du har gjort det rigtigt, vil grænsefladen se således ud:

Men hvis vi prøver at udføre anmodningen, returnerer serveren 401 kode, og uden autentifikation kan vi ikke få noget ud af denne server. Nå, det var i det store og hele forventet).

Tilføj anmodning om autentifikation

Som nævnt tidligere har vi et POST-endpoint /login, som modtager json-formatet som anmodningskrop: {"username": "", "password": ""}, hvor brugernavn og adgangskode (igen, som nævnt ovenfor) har betydning admin og adgangskode henholdsvis. Som svar returnerer denne endpoint json af typen {"token": ""}. Vi vil bruge den til autentificering. Lad os oprette RequestStep en node med navnet login, med Projekt fordi den fungerer som forælder create-post. Brug drag-and-drop til at flytte denne node i træet ovenfor noderne

• Anmodningstype: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Anmodningens krop: json med værdien {"username": "admin", "password": "password"}

Vi udfører anmodningen og modtager en to-hundred kodesvar med tokenet. Sådan:

Refactoring: vi fjerner duplikering af domænet

Foreløbigt er anmodningerne ikke samlet i et enkelt scenarie. Men det er ikke den eneste ulempe. Hvis man ser nærmere på, kan man bemærke, at domænet i det mindste duplikeres i begge anmodninger. Det er ikke godt. Det er på tide at refactorere denne del af det fremtidige scenarie, og det hjælper os med variable.

I første omgang udfylder variablerne den samme rolle som i andre lignende værktøjer og programmeringssprog — fjerner duplikering, forbedrer læsbarhed osv. Læs mere om variable i vores dokumentation. I dette tilfælde har vi brug for brugerdefinerede variable.

Lad os definere en variabel på Project-niveau for noden domæne med værdien https://testmace-quick-start.herokuapp.com. For at gøre det skal du

• åbne fanen for denne node og klikke på lommeregner-ikonet øverst til højre
• klik på + ADD VARIABLE
• indtast navnet og værdien for variablen
  I vores tilfælde vil dialogen med den tilføjede variabel se således ud:

OK. Nu, takket være arv, kan vi bruge denne variabel i efterkommere på enhver dybde. I vores tilfælde er det noderne login og create-post. For at bruge variablen i tekstfeltet skal du skrive ${}. For eksempel bliver URL'en for login til ${domain}/login, og dermed for create-post noden bliver URL'en som ${domain}/posts.

således har vi lidt forbedret scenariet ved at følge DRY-princippet.

Vi gemmer tokenet i variablen

Når vi er inde på emnet med variable, lad os uddybe dette lidt. I øjeblikket modtager vi ved en vellykket login fra serveren et autentifikations-token, som vi har brug for i de efterfølgende anmodninger. Lad os gemme dette token i en variabel. Da værdien af variablen bestemmes under udførelsen af scenariet, bruger vi en speciel mekanisme — dynamiske variable.

For starters, let's make a login request. In the tab Parsed of the response, hover over the token and from the context menu (which can be accessed by right-clicking or pressing the button …) select the item Assign to variable. A dialog will appear with the following fields:

• Sti — which part of the response is taken (in our case, this is body.token)
• Current value — what value lies on the Path (in our case, this is the token value)
• Variable name — the name of the variable where Current value it will be saved. In our case, this will be . Efter login, gå til venstre i udvidelsesmenuen, som vist på billedet nedenfor, hvor du bliver bedt om at acceptere sikkerhedsrisikoen ved at aktivere udvidelsesmanageren og installere tredjepartsudvidelser, som teamet
• Node — in which ancestor the variable will be created Variable name. Let's choose Project

The filled dialog looks as follows:

Now, with each execution of the node, the login dynamic variable . Efter login, gå til venstre i udvidelsesmenuen, som vist på billedet nedenfor, hvor du bliver bedt om at acceptere sikkerhedsrisikoen ved at aktivere udvidelsesmanageren og installere tredjepartsudvidelser, som teamet will be updated with a new value from the response. And this variable will be stored in Projekt the node and will be accessible to descendants through inheritance.

To refer to dynamic variables, you need to use the built-in variable $dynamicVar. For example, to access the saved token, you need to call ${$dynamicVar.token}.

Passing the authorization token in requests

In the previous steps, we received the authorization token, and all that's left is to add the header Authorization with the value Bearer to all requests requiring authorization, including create-post. There are several ways to do this:

1. Manually copy the token and add the authorization header to the relevant requests. This method works, but its use is limited to 'done and thrown away' type requests. It won't work for repeated execution of scenarios.
2. Use the functionality of autorisation.
3. Brug default headers

Using the second method seems obvious, but in the context of this article, such an approach... is uninteresting. I mean, the authorization mechanisms are more or less familiar to you from other tools (even though we have things like authorization inheritance) and are unlikely to raise questions.

Another matter is default headers! In short, default headers are inherited from ancestors’ HTTP headers that are automatically added to the request unless explicitly disabled. With this functionality, for example, you can implement custom authorization or simply eliminate duplication in scenarios. We will apply this feature to pass the token in headers.

Tidligere har vi forsigtigt gemt token i en dynamisk variabel $dynamicVar.token på niveauet Project-noden. Der skal nu gøres følgende:

1. Bestem default header Authorization med værdien Bearer ${$dynamicVar.token} på niveauet Project-noden. For at gøre dette skal du i Project-nodens interface åbne dialogboksen for standardoverskrifter (knappen Headers i øverste højre hjørne) og tilføje den relevante header. Dialogen med udfyldte værdier vil se således ud:
   
2. Fjern denne header fra login-anmodningen. Det er forståeligt: på tidspunktet for login har vi endnu ikke token, og vi vil netop etablere det med denne anmodning. Derfor skal vi i login-anmodningens interface under fanen Headers i området Inherited fjerne markeringen af Authorization-headeren.

Det er det hele. Nu vil autorisationsheaderen blive tilføjet til alle anmodninger, der er efterkommere af Project-noden, undtagen login-noden. Det betyder, at vi allerede har et skript klar til at blive kørt. Skriptet kan startes ved at vælge punktet Kør i kontekstmenuen for Project-noden.

Vi kontrollerer korrektheden af oprettelsen af indlægget

På dette tidspunkt kan vores skript logge ind, og ved at bruge autorisationstokenet oprette et indlæg. Men vi skal sikre os, at det nyoprettede indlæg har det korrekte navn. Med andre ord skal der gøres følgende:

• Sende en anmodning om at hente indlægget ved id,
• Kontrollere, at navnet, der kom fra serveren, svarer til det navn, der blev sendt ved oprettelsen af indlægget

Lad os se på det første trin. Da værdien af id bestemmes under kørsel af skriptet, skal der oprettes en dynamisk variabel (lad os kalde den postId) fra noden create-post på niveauet Project-noden. Hvordan dette gøres, ved vi allerede, det er tilstrækkeligt at henvise til afsnittet Vi gemmer tokenet i variablen. Det eneste, der er tilbage, er at skabe en anmodning om at hente indlægget ved dette id. For dette formål opretter vi RequestStep get-post med følgende parametre:

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

For at implementere det andet trin skal vi lære om Assertion noden. Assertion-noden er en node, der gør det muligt at skrive kontroller på bestemte anmodninger. Hver Assertion-node kan indeholde flere udsagn (kontroller). Du kan læse mere om alle typer assertions i vores dokumentationen. Vi vil bruge Compare assertion med operatoren equal. Der er flere måder at oprette assertions på:

1. Langsom. Opret en Assertion-nod manuelt fra kontekstmenuen i RequestStep-noden. I det oprettede Assertion-nod skal du tilføje den ønskede assertion og udfylde felterne.
2. Hurtig. Opret en Assertion-nod sammen med assertion fra svaret i RequestStep-noden via kontekstmenuen.

Vi bruger den anden metode. Her er, hvordan det vil se ud for vores tilfælde.

For dem, der ikke forstod, sker der følgende:

1. Foretag en anmodning i noden get-post
2. In the tab Parsed åbne kontekstmenuen for svaret og vælge Opret assertion -> Compare -> Lighed

Tillykke, vi har oprettet den første test! Simpelt, ikke sandt? Nu kan du køre scenariet helt igennem og nyde resultatet. Der er kun lidt tilbage at refaktorere og flytte title til en separat variabel. Men det lader vi være som en hjemmeopgave for jer :)

Konklusion

I denne vejledning har vi oprettet et fuldt scenarie og samtidig givet en oversigt over nogle funktioner i vores produkt. Selvfølgelig har vi ikke brugt hele funktionaliteten, og i de følgende artikler vil vi lave en detaljeret gennemgang af TestMace's muligheder. Hold øje med opdateringer!

P.S. For dem, der har svært ved at følge alle trin, har vi venligt optaget repository projektet fra artiklen. Du kan åbne det ved hjælp af Fil -> Åbn projekt og vælge mappen Projekt.

Kilde: habr.com