Përshëndetje të gjithëve. Ne po dalim ngadalë nga hija dhe vazhdojmë serinë e artikujve rreth produktit tonë. Pas artikullit të mëparshëm ne morëm shumë komente (në shumicën e rasteve pozitive), propozime dhe raporte për bug. Sot do t'ju tregojmë TestMace në veprim dhe do të keni mundësi të vlerësoni disa nga karakteristikat e aplikacionit tonë. Për një zhytje më të plotë, ju rekomandojmë të konsultoheni me dokumentacionin tonë në adresën http://docs-ru.testmace.com. Pra, le të fillojmë!

Instalimi

Të fillojmë me diçka të zakonshme. Aplikacioni është në dispozicion dhe vërtet mund të testohet në tre platforma — Linux, Windows, MacOS. Mund të shkarkoni instaluesin për sistemin operativ që ju intereson nga faqja jonë. Për ata që përdorin Linux, ka mundësinë e instalimit të paketës snap. Shpresojmë shumë që së shpejti do të arrijmë edhe në Microsoft Store dhe App Store (a ka nevojë? Si mendoni?).

Skenari i testit

Si subjekt të testimit, ne kemi zgjedhur skenarin standard në vijim:

• do të hyjmë: përdoruesi — admin, fjalëkalimi — password
• do të shtojmë një regjistrim të ri
• do të verifikojmë shtimin e saktë të regjistrimit

Do ta testojmë në https://testmace-quick-start.herokuapp.com/. Ky është një json-server, i përshtatshëm për testimin e aplikacioneve të tilla. Ne thjesht shtuam autorizimin me token në të gjitha rrugët e json-server dhe krijuam metodën login për të marrë këtë token. Do të avancojmë hapat hap pas hapi, duke përmirësuar gradualisht projektin tonë.

Krijimi i projektit dhe përpjekja për të krijuar një entitet pa autorizim

Së pari, do të krijojmë një projekt të ri (Skedari->Projekti i ri). Nëse po e aktivizoni aplikacionin për herë të parë, projekti i ri do të hapet automatikisht. Së pari, le të përpiqemi të bëjmë një kërkesë për krijimin e një regjistrimi të ri (ndoshta krijimi i regjistrimeve është i disponueshëm pa autorizim). Zgjidhni nga menuja kontekstuale të nodit Projekt opsionet Shto nod -> RequestStep. Si emër të nodit, le të caktojmë create-post. Si rezultat, një nod i ri do të krijohet në pemë dhe do të hapet skeda e këtij nodi. Le të vendosim parametrat e mëposhtëm të kërkesës:

• Lloji i kërkesës: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Trupi i kërkesës: json me vlerën {"title": "Postimi i ri për fillimin e shpejtë testmace"}
  Nëse e keni bërë gjithçka siç duhet, interface do të duket si më poshtë:

Megjithatë, nëse përpiqemi të kryejmë kërkesën, serveri do të kthejë kodin 401 dhe pa autorizim nuk do të kemi mundësi të veprojmë në këtë server. Siç pritej).

Shtojmë kërkesën për autorizim

Siç u përmend më parë, ne kemi një endpoint POST /login, i cili pranon si trup kërkese json të formatit: {"username": "<username>", "password": "<password>"}index username dhe password (po praprakisht, nga hyrja më lart) kanë kuptime admin dhe password përkatësisht. Në përgjigje, ky endpoint kthen json të formatit {"token": ""}. Do ta përdorim për autorizim. Do të krijojmë RequestStep një nyje me emrin login, si prind do të shërbejë Projekti nyja. Me ndihmën e drag-and-drop, zhvendosni këtë nyje në pemë lart se nyja create-post. Do t'i caktojmë kërkesës së sapokrijuar parametrat e mëposhtëm:

• Lloji i kërkesës: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Trupi i kërkesës: json me vlerën {"username": "admin", "password": "password"}

Do të kryejmë kërkesën dhe do të marrim kodin dyqind me token në përgjigje. Më ose ndryshe:

Rifaktorizimi: heqim përmbajtjen e kopjuar të domain-it

Derisa kërkesat nuk janë të lidhura në një skenar të vetëm. Por ky nuk është defekti i vetëm. Nëse e shikoni me kujdes, mund të vini re se si minimalisht domain-i kopjohet në të dyja kërkesat. Nuk është mirë. Koha për të rifaktorizuar këtë pjesë të skenarit të ardhshëm dhe në këtë do të na ndihmojnë variablat.

Në qasje të parë, variablat ushtrojnë të njëjtën rol si në mjete dhe gjuhë të tjera programimi — eliminimi i kopjimit, rritja e lexueshmërisë etj. Më shumë për variablat mund të lexoni në dokumentacionin tonë. Në këtë rast, do të na nevojiten variablat e përdoruesit.

Do të përcaktojmë në nivelin e Projektit të nyjës variablin domain me vlerën https://testmace-quick-start.herokuapp.com. Për këtë është e nevojshme

• Të hapni skedarin me këtë nyje dhe të klikoni në ikonën e kalkulatorit në të djathtë, lart
• Klikoni në + SHTO VARIABLIN
• Shkruani emrin dhe vlerën e variablit
  Në rastin tonë, dialogu me variablin e shtuar do të duket si më poshtë:

OK. Tani me anë të trashëgimisë mund të përdorim këtë variabël në pasardhësit e çdo niveli të thellësisë. Në rastin tonë janë nyjat login dhe create-post. Për të përdorur variablin në fushën tekstuale, është e nevojshme të shkruani ${}. Për shembull, url për login shndërrohet në ${domain}/login, përkatësisht për create-post nyjën url do të duket si ${domain}/posts.

Kështu, duke u udhëhequr nga parimi DRY, ne e përmirësuam pak skenarin.

Ruajmë token në variabël

Deri sa ndalon biseda për variablat, le të zhvillojmë pak këtë temë. Në momentin e tanishëm, në rast të suksesshëm logimi ne marrim nga serveri një token autorizimi, i cili do të na nevojitet në kërkesat e ardhshme. Le të ruajmë këtë token në një variabël. Pasi vlera e variablit do të përcaktohet gjatë ekzekutimit të skenarit, do të përdorim për këtë një mekanizëm të veçantë — variablat dinamikë.

Së pari, do të bëjmë një kërkesë për login. Në skedën Parsed përgjigjes, kaloni mbi tokenin dhe në menunë kontekstuale (e cila shkaktohet ose nga klikimi me të djathtën ose duke shtypur butonin …) zgjidhni opsionin Cakto në variabël. Një dialog do të shfaqet me fushat e mëposhtme:

• Path — cila pjesë e përgjigjes merret (në rastin tonë kjo është body.token)
• Current value — cilësimi që ndodhet në rrugën Path (në rastin tonë ky është vlera e tokenit)
• Emri i variablës — emri i variablës ku Current value do të ruhen. Në rastin tonë, kjo do të jetë token
• Nyja — në cilin nga paraardhësit do të krijohet variabla Emri i variablës. Zgjidhni Projektin

Dialogu i plotësuar duket si më poshtë:

Tani, me çdo ekzekutim të nyjës login variabla dinamike token do të përditësohet me vlerën e re nga përgjigjja. Dhe kjo variablë do të ruhet në Projekti nyjë dhe përmes trashëgimisë do të jetë e aksesueshme për pasardhësit.

Për të bërë kallëzim në variablat dinamike, është e nevojshme të përdorim variablën e integruar $dynamicVar. Për shembull, për të arritur tokenin e ruajtur, është e nevojshme të thërrasësh ${$dynamicVar.token}.

Përfshini tokenin e autorizimit në kërkesa

Në hapat e mëparshëm, morëm tokenin e autorizimit dhe gjithçka që duhet të bëjmë është të shtojmë titullin Authorization me vlerën Bearer në të gjitha kërkesat që kërkojnë autorizim, përfshirë edhe në create-post. Për këtë ekzistojnë disa mënyra:

1. Kopjoni manualisht tokenin dhe shtoni titullin e autorizimit në kërkesat e interesit. Ky metodë funksionon, megjithatë, aplikohet vetëm për kërkesat e tipit "bëra dhe hodha jashtë". Nuk është i përshtatshëm për ekzekutime të shumta të skenarëve.
2. Përdorni funksionalitetin të autorizimit.
3. Përdorni titujt në default

Përdorimi i mënyrës së dytë duket i qartë, megjithatë në kontekstin e këtij artikulli ky qasje… nuk është interesante. Epo, në të vërtetë: mekanizmi i autorizimeve plus minus njohur për ju nga vegla të tjera (edhe pse ne kemi gjëra si trashëgimia e autorizimeve) dhe me siguri nuk do të shkaktojë pyetje.

Një tjetër çështje janë titujt standard! Nëse i japim një përmbledhje, titujt standard janë tituj që trashëgohen nga parardhësit HTTP, të cilët shtohen automatikisht në kërkesë nëse nuk çaktivizohen shprehimisht. Me këtë funksionalitet, mund të realizojmë për shembull, një autorizim të personalizuar ose thjesht të eliminojmë ripërsëritjen në skenarë. Le ta zbatojmë këtë tipar për të kaluar token në tituj.

Më parë ne e ruajtëm me kujdes token në një variabël dinamike $dynamicVar.token në nivelin e nyjës Project. Mbetej të bëjmë të mëposhtmen:

1. Të përcaktojmë titullin standard Authorization me vlerën Bearer ${$dynamicVar.token} në nivelin e nyjës Project. Për këtë, në ndërfaqen e nyjës Project duhet të hapim dialogun me titujt standard (butoni Headers në këndin e sipërm djathtas) dhe të shtojmë titullin përkatës. Dialogu me vlerat e mbushura do të duket si më poshtë:
   
2. Çaktivizoni këtë titull nga kërkesa login. Kjo është e kuptueshme: në momentin e login, ende nuk kemi token dhe me këtë kërkesë pikërisht do ta vendosim atë. Prandaj, në ndërfaqen e kërkesës login në skedën Headers në zonën Inherited do të heqim shenjën nga titulli Authorization.

Këtu është gjithçka. Tani titulli i autorizimit do të shtohet në të gjitha kërkesat që janë pasardhës të nyjës Project, përveç nyjes login. Pra, në këtë etapë, kemi përgatitur tashmë skenarin dhe na mbetet vetëm ta nisnim atë. Mund ta nisim skenarin, duke zgjedhur opsionin Ekzekuto në menunë kontekstuale të nyjës Project.

Verifikojmë saktësinë e krijimit të postit

Në këtë etapë skenari ynë është në gjendje të bëjë login, dhe duke përdorur tokenin e autorizimit, të krijojë një postë. Megjithatë, duhet të sigurohemi që posti i sapokrijuar ka një emër të saktë. Kështu që në thelb mbetet të bëjmë të mëposhtmen:

• Të dërgojmë një kërkesë për të marrë postimin sipas id,
• Të kontrollojmë që emri, i ardhur nga serveri, përputhet me emrin e dërguar gjatë krijimit të postit.

Le të shqyrtojmë hapin e parë. Duke qenë se vlera e id përcaktohet gjatë ekzekutimit të skenarit, duhet të krijojmë një variabël dinamike (ta quajmë postId) nga nyja create-post në nivelin e nyjës Project. Si ta bëjmë këtë tashmë e dimë, mjafton të konsultohemi me seksionin Ruajmë token në variabël. Mbetej vetëm të krijojmë një kërkesë për të marrë postin sipas këtij id. Për këtë, do të krijojmë një RequestStep get-post me parametrat e mëposhtëm:

• Lloji i kërkesës: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Për të realizuar hapat e dytë, ne duhet të njihemi me Assertion nyjën. Një nyjë Assertion — është një nyjë që lejon të shkruhen verifikime për kërkesa të caktuara. Çdo nyjë Assertion mund të përmbajë disa propozime (verifikime). Më shumë rreth të gjitha llojeve të assertion-eve mund të lexoni në dokumentacionin. Ne do të përdorim Krahaso assertion me operatorin baraz. Ka disa mënyra për të krijuar assertion-e:

1. Të ngadalta. Në mënyrë manuale nga menuja kontekstuale e nyjës RequestStep ndiheni të krijoni një nyjë Assertion. Në nyjën e krijuar Assertion shtoni assertion-in që ju intereson dhe plotësoni fushat.
2. Të shpejta. Krijoni një nyjë Assertion së bashku me assertion-in nga përgjigjja e nyjës RequestStep me anë të menuve kontekstuale.

Le të përdorim mënyrën e dytë. Ja si do të duket për rastin tonë.

Për ata që nuk e kuptuan, këtu ndodh kjo:

1. Bëni një kërkesë në nyjën get-post
2. Në tab Parsed në përgjigje thirrni menunë kontekstuale dhe zgjidhni Krijo assertion -> Krahaso -> Baraz

Gratë të lutem, kemi krijuar testin tonë të parë! E thjeshtë, apo jo? Tani mund të ekzekutoni skenarin në tërësi dhe të shijoni rezultatin. Mbetet vetëm të refaktorizoni pak dhe të çoni titullin në një variabël të veçantë. Por ne do ta lëmë këtë si detyrë për ju)

Përfundim

Në këtë udhëzues kemi krijuar një skenar të plotë dhe po ashtu kemi bërë një përmbledhje të disa veçorive të produktit tonë. Sigurisht, nuk kemi shfrytëzuar të gjithë funksionalitetin dhe në artikujt e ardhshëm do të bëjmë një përmbledhje të hollësishme të mundësive të TestMace. Ndiqni përditësimet!

P.S. Për ata që janë të lodhur për të riprodhuar të gjitha hapat, ne me dashuri kemi përgatitur repozitori me projektin nga artikulli. Mund ta hapni duke Skedari -> Hapur projektin dhe zgjidhni dosjen Project.

Burimi: habr.com