Përshëndetje të gjithëve. Ne po dalim ngadalë nga hije dhe vazhdojmë serinë e artikujve rreth produktit tonë. Pas artikullit përmbledhës morëm shumë komente (kryesisht pozitive), propozime dhe raportime për defekte. Sot do të tregojmë në praktikë dhe ju do të mund të vlerësoni disa karakteristika të aplikacionit tonë. Për një imazh më të plotë, ju rekomandojmë të konsultoheni me dokumentacionin tonë në adresën . Pra, le të nisim!
Instalimi
TĂ« fillojmĂ« me tĂ« zakonshmet. Aplikacioni Ă«shtĂ« i disponueshĂ«m dhe me tĂ« vĂ«rtetĂ« testi bĂ«het nĂ« tri platforma â Linux, Windows, MacOS. Ju mund tĂ« shkarkoni instaluesin pĂ«r sistemin operativ tĂ« interesit nga . PĂ«r pĂ«rdoruesit e Linux-it ka mundĂ«sinĂ« e instalimit tĂ« . ShpresojmĂ« tĂ« arrijmĂ« sĂ« shpejti tĂ« jemi tĂ« pranishĂ«m edhe nĂ« Microsoft Store dhe App Store (por a Ă«shtĂ« e nevojshme? ĂfarĂ« mendoni?).
Scenari i eksperimentit
Kemi zgjedhur skenarin e mëposhtëm si subjekt:
- 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ë . Ky është një , i përsosur për testimin e aplikacioneve të tilla. Ne vetëm kemi shtuar autentifikimin me token në të gjitha ruterat e json-server dhe kemi krijuar metodën e login për të marrë këtë token. Do të ecim 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, le të krijojmë një projekt të ri (File->New project). Nëse po e ndizni aplikacionin për herë të parë, projekti i ri do të hapet automatikisht. Le të fillojmë me një kërkesë për të krijuar një regjistrim të ri (ndoshta krijimi i regjistrimeve është i disponueshëm pa autorizim). Zgjidhni në menunë kontekstuale Project pikët Add node -> RequestStep. Si emër të nodit do të caktojmë create-post. Si rezultat, në pemë do të krijohet një nod i ri dhe do të hapet skeda e këtij nodi. Le të caktojmë parametrat e mëposhtëm të kërkesës:
- Lloji i kërkesës: POST
- url:
- Trupi i kërkesës: json me vlerën
{"title": "New testmace quick start post"}
Nëse e keni bërë gjithçka siç duhet, ndërfaqja do të duket siçvijon:
MegjithatĂ«, nĂ«se pĂ«rpiqemi tĂ« realizojmĂ« kĂ«rkesĂ«n, serveri do tĂ« kthejĂ« kodin 401 dhe pa autorizim, nuk do tĂ« kemi mundĂ«si tĂ« punojmĂ« nĂ« kĂ«tĂ« server. ĂfarĂ« do tĂ« thoshim, e pritur).
Shtoni kërkesën për autorizim
Siç u tha më parë, ne kemi POST endpoint /login, i cili pranon si trup të kërkesës json të këtij lloji: {"username": "<username>", "password": "<password>"}, ku username dhe password (po ashtu, nga hyrja e mësipërme) kanë vlera admin dhe password përkatësisht. Në përgjigje, ky endpoint kthen json të këtij lloji {"token": "<token>}".Ne do ta përdorim për autorizim. Le të krijojmë RequestStep një nod me emrin kyçni, si prind do të shërbejë Project nodi. Me anë të drag-and-drop, lëvizni këtë nod në pemë lart se nodi create-post. Le të caktojmë parametrat e mëposhtëm për kërkesën e sapokrijuar:
- Lloji i kërkesës: POST
- url:
- Trupi i kërkesës: json me vlerën
{"username": "admin", "password": "password"}
Do ta realizojmë kërkesën dhe do të marrim një kod dyqind me tokenin në përgjigje. Kështu:
Rrëfimi: heqja e dublikimeve të domenit
Derisa kĂ«rkesat nuk lidhen nĂ« njĂ« skenar tĂ« vetĂ«m. Por kjo nuk Ă«shtĂ« e vetmja e metĂ«. NĂ«se shikoni me kujdes, do tĂ« vini re se tĂ« paktĂ«n domeni Ă«shtĂ« i dublikuar nĂ« tĂ« dyja kĂ«rkesat. E keqe. ĂshtĂ« koha pĂ«r tĂ« rifaktorizuar kĂ«tĂ« pjesĂ« tĂ« skenarit tĂ« ardhshĂ«m dhe ne do tĂ« ndihmojmĂ« me kĂ«tĂ« variablat.
NĂ« njĂ« kuptim tĂ« parĂ«, variablat kanĂ« tĂ« njĂ«jtin funksion si nĂ« instrumente dhe gjuhĂ« tĂ« tjera programuese â eliminimin e dublimeve, rritjen e lexueshmĂ«risĂ«, etj. MĂ« shumĂ« pĂ«r variablat mund tĂ« lexoni nĂ« . NĂ« kĂ«tĂ« rast na nevojiten variablat e pĂ«rdoruesve.
Le të përcaktojmë në nivelin e nodit të Projektit variablën domain me vlerë https://testmace-quick-start.herokuapp.com. Për këtë është e nevojshme
- Të hapim skedën e këtij nodi dhe të klikojmë në ikonën e kalkulatorit në të djathte lart
- Të klikojmë në + ADD VARIABLE
- Të shkruajmë emrin dhe vlerën e variablës
Në rastin tonë, dialogu me variablën e shtuar do të duket si më poshtë:
Mirë. Tani, për shkak të trashëgimisë, ne mund ta përdorim këtë variabël në pasardhësit e çdo niveli të thellësisë. Në rastin tonë, këto janë nodet kyçni dhe create-post. Për të përdorur variablën në fushën e tekstit, duhet të shkruajmë ${<variable_name>}. P.sh., url për login shndërrohet në ${domain}/login, përkatësisht për create-post nodi url do të duket si ${domain}/posts.
Në këtë mënyrë, duke u udhëhequr nga principi DRY, përmirësuam pak skenarin.
Ruajmë tokenin në variabël
Pasi po flasim pĂ«r variablat, le tĂ« zgjerojmĂ« pak kĂ«tĂ« temĂ«. Deri nĂ« kĂ«tĂ« moment, nĂ« rastin e login-it tĂ« suksesshĂ«m, ne marrim nga serveri njĂ« token autentikimi, tĂ« cilin do ta kemi nevojĂ« pĂ«r kĂ«rkesat e ardhshme. Le tĂ« ruajmĂ« kĂ«tĂ« token nĂ« njĂ« variabĂ«l. Duke qenĂ« se vlera e variablĂ«s do tĂ« pĂ«rcaktohet gjatĂ« ekzekutimit tĂ« skenarit, do tĂ« pĂ«rdorim pĂ«r kĂ«tĂ« njĂ« mekanizĂ«m tĂ« veçantĂ« â .
SĂ« pari, do tĂ« realizojmĂ« kĂ«rkesĂ«n pĂ«r login. NĂ« skedĂ«n Parsed pĂ«rgjigjen, vendosni kursorin mbi tokenin dhe nĂ« menunĂ« kontekstuale (e cila thirret duke klikuar me butonin e djathtĂ« tĂ« miut ose duke shtypur butonin âŠ) zgjidhni pikĂ«n Ă«shtĂ« ideal. Le tĂ« shqyrtojmĂ« sĂ« bashku se si funksionon. NĂ« skedĂ«n e pĂ«rgjigjes tĂ« nyjĂ«s id nĂ« menunĂ« e kontekstit, duhet tĂ« zgjidhni opsionin. NjĂ« dialog do tĂ« shfaqet me fushat e mĂ«poshtme:
- Path â cili pjesĂ« e pĂ«rgjigjes merret (nĂ« rastin tonĂ« kjo Ă«shtĂ«
body.token) - Vlera aktuale â cila vlerĂ« ndodhet nĂ« rrugĂ«n Path (nĂ« rastin tonĂ«, kjo Ă«shtĂ« vlera e tokenit)
- â nĂ« cilin nga pararendĂ«sit do tĂ« krijojmĂ« variablĂ«n dinamike. Do tĂ« zgjidhim â emri i variablĂ«s ku Vlera aktuale do tĂ« ruhet. NĂ« rastin tonĂ«, kjo do tĂ« jetĂ«
token - Node â nĂ« cilin nga paraardhĂ«sit do tĂ« krijohet variabla â nĂ« cilin nga pararendĂ«sit do tĂ« krijojmĂ« variablĂ«n dinamike. Do tĂ« zgjidhim. Do tĂ« zgjedhim Project
Dialogu i plotësuar duket si më poshtë:
Tani, çdo herë që ekzekutohet nodi kyçni variabla dinamike token do të përditësohet me vlerën e re nga përgjigjja. Dhe kjo variabla do të ruhet në Project nodi dhe përmes trashëgimisë do të jetë e disponueshme për pasardhësit.
Për t'u referuar variablave dinamikë, është e nevojshme të përdoret $dynamicVar. Për shembull, për të arritur në token e ruajtur, është e nevojshme të thërrasësh ${$dynamicVar.token}.
Përshtatni tokenin e autorizimit në kërkesa
Në hapat e mëparshëm, ne morëm tokenin e autorizimit dhe gjithçka që duhet të bëjmë është të shtojmë një kokë Authorization me vlerën Bearer në të gjitha kërkesat që kërkojnë autorizim, duke përfshirë dhe në create-post. Për këtë ka disa mënyra:
- Të kopjoni manualisht tokenin dhe të shtoni kokën e autorizimit në kërkesat që ju interesojnë. Ky është një mënyrë funksionale, por përdorimi i saj kufizohet vetëm në kërkesat e tipit 'bëra dhe e hodha'. Nuk do të funksionojë për ekzekutime të shumta të skenarëve
- Të përdorni funksionalitetin .
- PĂ«rdorni
Përdorimi i mënyrës së dytë duket i qartë, megjithatë në kontekstin e këtij artikulli ky qasje⊠nuk është interesante. Po të jemi të sinqertë: mekanizmat e autorizimit plus-minus janë të njohura për ju nga mjetet e tjera (edhe pse kemi gjëra si ) dhe është e vështirë të ngjallin pyetje.
Një tjetër gjë janë kokat standarde! Nëse duhet ta thjeshtëzojmë, kokat standarde janë kokat HTTP të trashëguara nga paraardhësit, të cilat në mënyrë standarde shtohen në kërkesë nëse nuk janë shkyçur shprehimisht. Me këtë funksionalitet, për shembull, mund të realizoni një autorizim të personalizuar ose thjesht të evitoni shumimin në skenarë. Do ta aplikojmë këtë funksionalitet për të përfshirë tokenin në kokat.
Kur ne paraprakisht ruajmë tokenin në variablën dinamike $dynamicVar.token në nivelin e nodit Project. Na mbetet të bëjmë si më poshtë:
- Të përcaktojmë kokën standarde
Authorizationme vlerëBearer ${$dynamicVar.token}në nivelin e nodit Project. Për këtë, në ndërfaqen e nodit Project është e nevojshme të hapim dialogun me kokat standarde (butoni Headers në këndin e sipërm të djathtë) dhe të shtojmë kokën përkatëse. Dialogu me vlerat e plota do të duket si më poshtë:
- Ăaktivizoni kĂ«tĂ« kokĂ« nga kĂ«rkesa e login. Kjo Ă«shtĂ« e qartĂ«: nĂ« momentin e login-it nuk e kemi ende tokenin dhe me kĂ«tĂ« kĂ«rkesĂ« do ta vendosim atĂ«. Prandaj nĂ« ndĂ«rfaqen e kĂ«rkesĂ«s sĂ« login nĂ« skedĂ«n Headers nĂ« zonĂ«n Inherited tĂ« heqim markĂ«n nga koka e autorizimit.
Kjo është gjithçka. Tani, koka e autorizimit do të shtohet në të gjitha kërkesat që janë pasardhës të nodit Project, përveç nodit të login-it. Kështu, në këtë fazë kemi një skenar të gatshëm dhe na mbetet vetëm ta fillojmë. Mund ta fillojmë skenarin duke zgjedhur pikën Ekzekuto në menunë kontekstuale të nodit Project.
Kontrolloni saktësinë e krijimit të postit
Në këtë fazë skenari ynë di të bëjë login dhe, duke përdorur tokenin e autorizimit, të krijojë një post. Megjithatë, na nevojitet të sigurohemi që posti i ri të ketë emrin korrekt. Pra, në thelb, na mbetet të bëjmë sa vijon:
- Të dërgojmë një kërkesë për të marrë postin sipas id,
- Të kontrollojmë që emri, që ka ardhur nga serveri, është në përputhje me emrin e kaluar gjatë krijimit të postit
Le t'i hedhim një sy hapit të parë. Duke u bazuar në atë që id përcaktohet gjatë ekzekutimit të skriptit, duhet të krijojmë një variablë dinamike (të quajtur postId) nga nodi create-post në nivelin e nodit Project. Si ta bëjmë këtë, ne e dimë tashmë, është e mjaftueshme të citojmë seksionin Ruajmë tokenin në variabël. Na mbetet vetëm të krijojmë një kërkesë për të marrë postin sipas këtij id. Për këtë, le të krijojmë një RequestStep get-post me parametrat e mëposhtëm:
- Tipi i kërkesës: GET
- URL: ${domain}/posts/${$dynamicVar.postId}
PĂ«r realizimin e hapit tĂ« dytĂ«, na nevojitet tĂ« njihemi me nodi. Nodi Assertion Ă«shtĂ« njĂ« nodĂ« qĂ« lejon tĂ« shkruhen verifikime pĂ«r kĂ«rkesa tĂ« caktuara. Ădo nodi Assertion mund tĂ« pĂ«rmbajĂ« disa pohime (kontrollesh). MĂ« shumĂ« rreth tĂ« gjitha llojeve tĂ« pohimeve do tĂ« mund tĂ« lexoni nĂ« . Ne do ta pĂ«rdorim Compare pohimin me operatorin equal. Ka disa mĂ«nyra pĂ«r tĂ« krijuar pohime:
- Më e gjatë. Nga menuja kontekstuale të nodit RequestStep, krijoni një nodë Assertion manualisht. Në nodin e krijuar Assertion, shtoni pohimin që ju intereson dhe plotësoni fushat.
- Shpejt. Krijoni një nod të Assertsionit së bashku me assertion-in nga përgjigja e nodit RequestStep përmes menusë kontekstuale
Të dyta përdorim. Kështu do të duket për rastin tonë.
Për ata që nuk e kuptuan, këtu ndodh për siguiente:
- Bëni një kërkesë në nodin get-post
- Në skedën Parsed të përgjigjes, thoni menusë kontekstuale dhe zgjidhni Krijo assertion -> Compare -> Baraz
Urime, krijuam testin tonë të parë! E thjeshtë, a nuk është e vërtetë? Tani mund të ekzekutoni skenarin plotësisht dhe të shijoni rezultatin. Ka mbetur për të refaktorizuar pak dhe nxjerrë title në një variabël të veçantë. Por ne do ta lëmë këtë për ju si detyrë shtëpie)
PĂ«rfundimi
Në këtë udhëzues ne krijuam një skenar të plotë dhe gjithashtu bëmë një përmbledhje të disa veçorive të produktit tonë. Sigurisht, ne nuk e shfrytëzuam të gjithë funksionalitetin dhe në artikujt e ardhshëm do të bëjmë një përmbledhje të detajuar të mundësive të TestMace. Qëndroni në kontroll të azhurnimeve!
P.S. Për ata që e kanë të vështirë të riprodhojnë të gjitha hapat, ne kemi vendosur me mirësjellje me projektin nga artikulli. Mund ta hapni me File -> Hap projektin dhe zgjidhni dosjen Projekt.
Burimi: habr.com
