Hej alle. Vi er langsomt ved at komme ud af skyggerne og fortsætter serien af artikler om vores produkt. Efter gennemgangsartikel, modtog vi en masse feedback (for det meste positive), forslag og fejlrapporter. I dag vil vi vise i aktion, og du vil være i stand til at sætte pris på nogle af funktionerne i vores applikation. For en mere fuldstændig fordybelse råder jeg dig til at henvise til vores dokumentation på . Så lad os gå!
Installation
Lad os starte med banaliteten. Applikationen er tilgængelig og faktisk testet på tre platforme - Linux, Windows, MacOS. Du kan downloade installationsprogrammet til det OS, du er interesseret i, fra . For Linux-brugere er det muligt at installere . Vi håber virkelig, at Microsoft Store og App Store snart vil komme rundt (er det nødvendigt? Hvad synes du?).
Eksperimentelt scenarie
Vi valgte følgende standardscenarie som vores testperson:
- Login: bruger - admin, adgangskode - adgangskode
- tilføje en ny post
- Lad os kontrollere, at posten blev tilføjet korrekt
Vi vil teste på . Dette er normalt , perfekt til at teste sådanne applikationer. Vi har lige tilføjet godkendelse via token til alle json-server-ruter og oprettet en login-metode til at modtage dette token. Vi vil bevæge os gradvist og gradvist forbedre vores projekt.
Oprettelse af et projekt og forsøg på at oprette en enhed uden autorisation
Lad os først oprette et nyt projekt (File (Felt)->Nyt projekt). Hvis du starter applikationen for første gang, åbnes et nyt projekt automatisk. Lad os først prøve at lave en anmodning om at oprette en ny post (i tilfælde af at oprettelse af poster er tilgængelig uden autorisation). Vælg elementer fra kontekstmenuen for projektknudepunktet Tilføj knude -> RequestStep. Indstil nodenavnet til oprette-indlæg. Som et resultat vil der blive oprettet en ny node i træet, og en fane for denne node åbnes. Lad os indstille følgende anmodningsparametre:
- Anmodningstype: POST
- url:
- Anmodningstekst: json med værdi
{"title": "New testmace quick start post"}
Hvis du gjorde alt korrekt, vil grænsefladen se sådan ud:
Men hvis vi forsøger at opfylde anmodningen, vil serveren returnere en 401-kode, og uden autorisation får vi ikke noget på denne server. Nå, generelt, som forventet).
Tilføjelse af en godkendelsesanmodning
Som allerede nævnt har vi et POST-endepunkt /login, som tager json som en anmodningstekst af formularen: {"username": "<username>", "password": "<password>"}Hvor username и password (igen, fra det indledende afsnit ovenfor) har betydninger admin и password henholdsvis. Som svar returnerer dette endepunkt json like {"token": "<token>"}. Vi vil bruge det til autorisation. Lad os skabe RequestStep node med navn Logge på, vil fungere som en forfader Projekt node Brug træk-og-slip til at flytte en given node i træet højere end noden oprette-indlæg. Lad os indstille følgende parametre til den nyoprettede anmodning:
- Anmodningstype: POST
- url:
- Anmodningstekst: json med værdi
{"username": "admin", "password": "password"}
Lad os udføre anmodningen og modtage den to hundrededel kode med tokenet i svaret. Noget som dette:
Refactoring: fjernelse af domæneduplikering
Indtil videre er anmodningerne ikke knyttet til et enkelt script. Men dette er ikke den eneste ulempe. Hvis du ser godt efter, vil du bemærke, at domænet i det mindste er duplikeret i begge anmodninger. Ikke godt. Det er tid til at refaktorisere denne del af det fremtidige script, og variabler vil hjælpe os med dette.
Til en første tilnærmelse tjener variabler den samme rolle som i andre lignende værktøjer og programmeringssprog - eliminerer duplikering, øger læsbarheden osv. Du kan læse mere om variabler i . I dette tilfælde skal vi bruge brugervariabler.
Lad os definere en variabel på projektnodeniveau domain med betydningen https://testmace-quick-start.herokuapp.com. Til dette er det nødvendigt
- Åbn fanen med denne node og klik på lommeregnerikonet øverst til højre
- Klik på + TILFØJ VARIABEL
- Indtast variabelnavn og værdi
I vores tilfælde vil dialogen med den tilføjede variabel se sådan ud:
OKAY. Nu, på grund af arv, kan vi bruge denne variabel i efterkommere af ethvert redeniveau. I vores tilfælde er disse noder Logge på и oprette-indlæg. For at bruge en variabel i et tekstfelt skal du skrive ${<variable_name>}. For eksempel konverteres login url til ${domain}/login, henholdsvis for oprette-indlæg node url vil se ud ${domain}/posts.
Derfor har vi, styret af DRY-princippet, forbedret scenariet en smule.
Gem tokenet til en variabel
Da vi taler om variabler, lad os udvide dette emne lidt. I øjeblikket, i tilfælde af vellykket login, modtager vi fra serveren et autorisationstoken, som vi skal bruge i efterfølgende anmodninger. Lad os gemme dette token i en variabel. Fordi værdien af variablen vil blive bestemt under scriptudførelse, vi bruger en speciel mekanisme til dette - .
Lad os først udføre en login-anmodning. I fanen Analyseret svar, flyt markøren over tokenet og i kontekstmenuen (som kaldes enten med højre museknap eller ved at klikke på knappen ...) vælg punktet Tildel til variabel. Der vises en dialogboks med følgende felter:
- Sti — hvilken del af svaret er taget (i vores tilfælde er det
body.token) - Nuværende værdi - hvilken værdi ligger langs stien (i vores tilfælde er dette symbolværdien)
- Variabelt navn — navnet på variablen hvor Nuværende værdi vil blive bevaret. I vores tilfælde vil det være det
token - Node — i hvilken af forfædrene variablen vil blive oprettet Variabelt navn. Lad os vælge Projekt
Den færdige dialog ser således ud:
Nu hver gang noden udføres Logge på dynamisk variabel token vil blive opdateret med den nye værdi fra svaret. Og denne variabel vil blive gemt i Projekt node og vil takket være arv være tilgængelig for efterkommere.
For at få adgang til dynamiske variabler skal du bruge $dynamicVar. For at få adgang til et gemt token skal du for eksempel ringe ${$dynamicVar.token}.
Vi videregiver godkendelsestokenet til anmodninger
I de foregående trin modtog vi godkendelsestokenet, og alt hvad vi skal gøre er at tilføje en overskrift Authorization med mening Bearer <tokenValue> i alle anmodninger, der kræver autorisation, herunder oprette-indlæg. Der er flere måder at gøre dette på:
- Kopier tokenet manuelt, og tilføj en autorisationsoverskrift til interesseanmodningerne. Metoden virker, men dens brug er kun begrænset til anmodninger af typen "lavet og smidt væk". Ikke egnet til gentagen udførelse af scripts
- Brug funktionaliteten .
- Brug
At bruge den anden metode virker indlysende, men i sammenhæng med denne artikel er denne tilgang... uinteressant. Nå, virkelig: autorisationsmekanismen plus minus kender dig fra andre værktøjer (selvom vi har ting som f.eks. ) og vil sandsynligvis ikke rejse spørgsmål.
En anden ting er standardoverskrifterne! I en nøddeskal er standardheadere nedarvede HTTP-headere, der føjes til anmodningen som standard, medmindre de udtrykkeligt er deaktiveret. Ved at bruge denne funktionalitet kan du for eksempel implementere tilpasset autorisation eller blot slippe for duplikering i scripts. Lad os bruge denne funktion til at sende et token i overskrifterne.
Tidligere gemte vi forsigtigt tokenet i en dynamisk variabel $dynamicVar.token på projektknudeniveau. Det eneste der er tilbage er at gøre følgende:
- Definer standardtitel
Authorizationmed betydningenBearer ${$dynamicVar.token}på projektknudeniveau. For at gøre dette skal du i projektgrænsefladen på noden åbne en dialog med standardoverskrifter (knap Headers i øverste højre hjørne) og tilføj en tilsvarende titel. Dialogen med de udfyldte værdier vil se sådan ud:
- Deaktiver denne overskrift fra login-anmodningen. Dette er forståeligt: På tidspunktet for login har vi endnu ikke et token, og vi vil installere det med denne anmodning. Derfor, i login-grænsefladen for anmodningen i fanen Headers inden for Arvelige fjern markeringen i Autorisationsoverskriften.
Det er alt. Nu vil autorisationshovedet blive tilføjet til alle anmodninger, der er underordnede af projektnoden, undtagen login-noden. Det viser sig, at vi på dette tidspunkt allerede har et manuskript klar, og alt hvad vi skal gøre er at starte det. Du kan køre scriptet ved at vælge Kør i projektnodens kontekstmenu.
Kontrol af rigtigheden af postoprettelsen
På dette trin kan vores script logge ind og ved hjælp af et godkendelsestoken oprette et opslag. Vi skal dog sikre os, at det nyoprettede indlæg har det korrekte navn. Det vil sige, at der i bund og grund kun er tilbage at gøre følgende:
- Send en anmodning om at modtage et indlæg med id,
- Tjek, at det navn, der modtages fra serveren, stemmer overens med det navn, der blev sendt, da du oprettede indlægget
Lad os se på det første skridt. Da id-værdien bestemmes under scriptudførelse, skal du oprette en dynamisk variabel (lad os kalde det postId) fra node oprette-indlæg på projektknudeniveau. Vi ved allerede, hvordan man gør dette, se blot afsnittet Gem tokenet til en variabel. Det eneste, der er tilbage, er at oprette en anmodning om at modtage et indlæg ved hjælp af dette id. For at gøre dette, lad os oprette et RequestStep få-post med følgende parametre:
- Anmodningstype: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
For at implementere det andet trin, skal vi stifte bekendtskab med knude. En Assertion node er en node, der giver dig mulighed for at skrive checks for specifikke anmodninger. Hver påstandsknude kan indeholde flere påstande (checks). Du kan læse mere om alle typer påstande fra vores . Vi vil bruge Compare påstand med operatør equal. Der er flere måder at oprette påstande på:
- Lang. Opret manuelt en Assertion-node fra kontekstmenuen i RequestStep-noden. I den oprettede Assertion node skal du tilføje interessepåstanden og udfylde felterne.
- Hurtig. Opret en påstandsknude sammen med en påstand fra RequestStep-knudesvaret ved hjælp af kontekstmenuen
Lad os bruge den anden metode. Sådan kommer det til at se ud for vores sag.
For dem, der ikke forstår, her er hvad der sker:
- Lav en anmodning i noden få-post
- I fanen Analyseret svar, ring til kontekstmenuen og vælg Skab påstand -> Sammenlign -> Ens
Tillykke, vi har lavet vores første test! Simpelt, er det ikke? Nu kan du køre scriptet fuldstændigt og nyde resultatet. Det eneste, der er tilbage, er at omstrukturere det lidt og tage det ud title til en separat variabel. Men vi overlader dette til dig som hjemmearbejde)
Konklusion
I denne guide har vi lavet et fuldt udbygget scenario og samtidig gennemgået nogle af funktionerne i vores produkt. Vi brugte selvfølgelig ikke al funktionaliteten, og i de følgende artikler vil vi give et detaljeret overblik over TestMace's muligheder. Bliv hængende!
P.S. For dem, der er for dovne til at gengive alle trinene, har vi venligst optaget med projektet fra artiklen. Du kan åbne den med File (Felt) -> Åbent projekt og vælg mappen Projekt.
Kilde: www.habr.com