Hei alle sammen. Vi kommer sakte ut av skyggene og fortsetter serien med artikler om produktet vårt. Etter gjennomgangsartikkel, fikk vi mange tilbakemeldinger (for det meste positive), forslag og feilrapporter. I dag skal vi vise i aksjon, og du vil kunne sette pris på noen av funksjonene i applikasjonen vår. For en mer fullstendig fordypning anbefaler jeg deg å se vår dokumentasjon på . Så la oss gå!
Installasjon
La oss starte med banaliteten. Applikasjonen er tilgjengelig og faktisk testet på tre plattformer - Linux, Windows, MacOS. Du kan laste ned installasjonsprogrammet for operativsystemet du er interessert i fra . For Linux-brukere er det mulig å installere . Vi håper virkelig at Microsoft Store og App Store snart vil komme seg rundt (er det nødvendig? Hva synes du?).
Eksperimentelt scenario
Vi valgte følgende standardscenario som vårt testobjekt:
- Innlogging: bruker - admin, passord - passord
- legge til en ny oppføring
- La oss sjekke at posten ble lagt til på riktig måte
Vi skal teste på . Dette er normalt , perfekt for å teste slike applikasjoner. Vi har nettopp lagt til autorisasjon via token til alle json-server-ruter og opprettet en påloggingsmetode for å motta dette tokenet. Vi vil bevege oss gradvis, og gradvis forbedre prosjektet vårt.
Opprette et prosjekt og prøve å opprette en enhet uten autorisasjon
La oss først lage et nytt prosjekt (filet->Nytt prosjekt). Hvis du starter applikasjonen for første gang, åpnes et nytt prosjekt automatisk. La oss først prøve å lage en forespørsel om å opprette en ny post (i tilfelle opprettelse av poster er tilgjengelig uten autorisasjon). Velg elementer fra kontekstmenyen for prosjektnoden Legg til node -> RequestStep. Sett nodenavnet til opprette-innlegg. Som et resultat vil en ny node bli opprettet i treet og en fane for denne noden åpnes. La oss angi følgende forespørselsparametere:
- Forespørselstype: POST
- url:
- Forespørselstekst: json med verdi
{"title": "New testmace quick start post"}
Hvis du gjorde alt riktig, vil grensesnittet se slik ut:
Men hvis vi prøver å oppfylle forespørselen, vil serveren returnere en 401-kode og uten autorisasjon får vi ikke noe på denne serveren. Vel, generelt, som forventet).
Legger til en autorisasjonsforespørsel
Som allerede sagt har vi et POST-endepunkt /login, som tar json som en forespørselstekst i skjemaet: {"username": "<username>", "password": "<password>"}Der username и password (igjen, fra det innledende avsnittet ovenfor) har betydninger admin и password hhv. Som svar returnerer dette endepunktet json like {"token": "<token>"}. Vi vil bruke det for autorisasjon. La oss skape RequestStep node med navn Logg inn, vil fungere som en stamfar Prosjekt node Bruk dra-og-slipp, flytt en gitt node i treet høyere enn noden opprette-innlegg. La oss sette følgende parametere til den nyopprettede forespørselen:
- Forespørselstype: POST
- url:
- Forespørselstekst: json med verdi
{"username": "admin", "password": "password"}
La oss utføre forespørselen og motta tohundrekoden med token i svaret. Noe sånt som dette:
Refaktorering: fjerner domeneduplisering
Så langt er ikke forespørslene knyttet til et enkelt skript. Men dette er ikke den eneste ulempen. Hvis du ser nøye etter, vil du legge merke til at i det minste domenet er duplisert i begge forespørslene. Ikke bra. Det er på tide å refaktorisere denne delen av det fremtidige skriptet, og variabler vil hjelpe oss med dette.
Til en første tilnærming tjener variabler samme rolle som i andre lignende verktøy og programmeringsspråk - eliminerer duplisering, øker lesbarheten, etc. Du kan lese mer om variabler i . I dette tilfellet trenger vi brukervariabler.
La oss definere en variabel på prosjektnodenivå domain med mening https://testmace-quick-start.herokuapp.com... Dette krever
- Åpne fanen med denne noden og klikk på kalkulatorikonet øverst til høyre
- Klikk på + LEGG TIL VARIABEL
- Skriv inn variabelnavn og verdi
I vårt tilfelle vil dialogen med den tilføyde variabelen se slik ut:
OK. Nå, på grunn av arv, kan vi bruke denne variabelen i etterkommere av ethvert hekkenivå. I vårt tilfelle er dette noder Logg inn и opprette-innlegg. For å bruke en variabel i et tekstfelt må du skrive ${<variable_name>}. For eksempel blir påloggings-url konvertert til ${domain}/login, henholdsvis for opprette-innlegg node url vil se ut ${domain}/posts.
Derfor har vi, styrt av DRY-prinsippet, forbedret scenarioet litt.
Lagre tokenet til en variabel
Siden vi snakker om variabler, la oss utvide dette emnet litt. For øyeblikket, i tilfelle vellykket pålogging, mottar vi fra serveren et autorisasjonstoken, som vi trenger i påfølgende forespørsler. La oss lagre dette tokenet i en variabel. Fordi verdien av variabelen vil bli bestemt under kjøring av skript, vi bruker en spesiell mekanisme for dette - .
La oss først utføre en påloggingsforespørsel. I fanen Analisert svar, flytt markøren over symbolet og i kontekstmenyen (som kalles enten med høyre museknapp eller ved å klikke på knappen ...) velg elementet Tilordne til variabel. En dialogboks vises med følgende felt:
- Sti — hvilken del av svaret som tas (i vårt tilfelle er det det
body.token) - Nåværende verdi - hvilken verdi ligger langs stien (i vårt tilfelle er dette symbolverdien)
- Variabel navn — navnet på variabelen hvor Nåværende verdi vil bli bevart. I vårt tilfelle vil det være det
token - Node — i hvilken av forfedrene variabelen vil bli opprettet Variabel navn. La oss velge Prosjekt
Den fullførte dialogboksen ser slik ut:
Nå hver gang noden kjøres Logg inn dynamisk variabel token vil bli oppdatert med den nye verdien fra svaret. Og denne variabelen vil bli lagret i Prosjekt node og, takket være arv, vil være tilgjengelig for etterkommere.
For å få tilgang til dynamiske variabler må du bruke $dynamicVar. For å få tilgang til et lagret token, må du for eksempel ringe ${$dynamicVar.token}.
Vi overfører autorisasjonstokenet til forespørsler
I de forrige trinnene mottok vi autorisasjonstokenet, og alt vi trenger å gjøre er å legge til en overskrift Authorization med mening Bearer <tokenValue> i alle forespørsler som krever autorisasjon, inkludert opprette-innlegg. Det er flere måter å gjøre dette på:
- Kopier tokenet manuelt og legg til en autorisasjonsoverskrift til interesseforespørslene. Metoden fungerer, men bruken er begrenset til forespørsler av typen "laget og kastet". Ikke egnet for gjentatt utførelse av skript
- Bruk funksjonaliteten .
- Bruk
Å bruke den andre metoden virker opplagt, men i sammenheng med denne artikkelen er denne tilnærmingen... uinteressant. Vel, egentlig: autorisasjonsmekanismen pluss minus er kjent for deg fra andre verktøy (selv om vi har ting som ) og vil neppe reise spørsmål.
En annen ting er standardhodene! I et nøtteskall er standardhoder arvede HTTP-hoder som legges til forespørselen som standard med mindre de er eksplisitt deaktivert. Ved å bruke denne funksjonaliteten kan du for eksempel implementere tilpasset autorisasjon eller rett og slett bli kvitt duplisering i skript. La oss bruke denne funksjonen til å sende et token i overskriftene.
Tidligere har vi forsiktig lagret tokenet til en dynamisk variabel $dynamicVar.token på prosjektnodenivå. Alt som gjenstår er å gjøre følgende:
- Definer standardtittel
Authorizationmed meningBearer ${$dynamicVar.token}på prosjektnodenivå. For å gjøre dette, i prosjektgrensesnittet til noden må du åpne en dialog med standardoverskrifter (knapp Headers i øvre høyre hjørne) og legg til en tilsvarende tittel. Dialogen med de utfylte verdiene vil se slik ut:
- Deaktiver denne overskriften fra påloggingsforespørselen. Dette er forståelig: på påloggingstidspunktet har vi ennå ikke et token, og vi vil installere det med denne forespørselen. Derfor, i påloggingsgrensesnittet til forespørselen i fanen Headers i området Arvet fjern merket for Autorisasjonsoverskriften.
Det er alt. Nå vil autorisasjonsoverskriften legges til alle forespørsler som er underordnet prosjektnoden, bortsett fra påloggingsnoden. Det viser seg at vi på dette stadiet allerede har et manus klart og alt vi trenger å gjøre er å lansere det. Du kan kjøre skriptet ved å velge Kjør i Prosjektnodens kontekstmeny.
Kontrollerer riktigheten av innlegget
På dette stadiet kan skriptet vårt logge på og ved å bruke et autorisasjonstoken opprette et innlegg. Vi må imidlertid sørge for at det nyopprettede innlegget har riktig navn. Det vil si at alt som gjenstår er å gjøre følgende:
- Send en forespørsel om å motta et innlegg med id,
- Sjekk at navnet mottatt fra serveren samsvarer med navnet som ble sendt når du opprettet innlegget
La oss se på det første trinnet. Siden id-verdien bestemmes under kjøring av skript, må du lage en dynamisk variabel (la oss kalle den postId) fra node opprette-innlegg på prosjektnodenivå. Vi vet allerede hvordan du gjør dette, bare se avsnittet Lagre tokenet til en variabel. Alt som gjenstår er å opprette en forespørsel om å motta et innlegg med denne IDen. For å gjøre dette, la oss lage et RequestStep få-post med følgende parametere:
- Forespørselstype: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
For å implementere det andre trinnet, må vi bli kjent med knute. En Assertion node er en node som lar deg skrive sjekker for spesifikke forespørsler. Hver påstandsnode kan inneholde flere påstander (sjekker). Du kan lese mer om alle typer påstander fra vår . Vi vil bruke Compare påstand med operatør equal. Det er flere måter å lage påstander på:
- Lang. Opprett en Assertion-node manuelt fra kontekstmenyen til RequestStep-noden. I den opprettede påstandsnoden legger du til påstanden om interesse og fyller ut feltene.
- Fort. Opprett en påstandsnode sammen med en påstand fra RequestStep-nodesvaret ved å bruke kontekstmenyen
La oss bruke den andre metoden. Slik vil det se ut for vårt tilfelle.
For de som ikke forstår, her er hva som skjer:
- Lag en forespørsel i noden få-post
- I fanen Analisert svar, ring opp kontekstmenyen og velg Lag påstand -> Sammenligne -> Lik
Gratulerer, vi har laget vår første test! Enkelt, ikke sant? Nå kan du kjøre skriptet fullstendig og nyte resultatet. Det gjenstår bare å refaktorere den litt og ta den ut title inn i en egen variabel. Men vi overlater dette til deg som lekser)
Konklusjon
I denne guiden har vi laget et fullverdig scenario og samtidig gjennomgått noen av funksjonene til produktet vårt. Vi brukte selvfølgelig ikke all funksjonaliteten, og i de følgende artiklene vil vi gi en detaljert oversikt over egenskapene til TestMace. Følg med!
PS For de som er for late til å gjengi alle trinnene, har vi vennligst tatt opp med prosjektet fra artikkelen. Du kan åpne den med filet -> Åpent prosjekt og velg Project-mappen.
Kilde: www.habr.com