Hola a tots. A poc a poc estem sortint de l'ombra i seguim la sèrie d'articles sobre el nostre producte. Després anterior article de revisió, vam rebre molts comentaris (sobretot positius), suggeriments i informes d'errors. Avui us mostrarem TestMace en acció i podreu apreciar algunes de les característiques de la nostra aplicació. Per a una immersió més completa, us recomano que consulteu la nostra documentació a http://docs-ru.testmace.com. Així doncs, anem!

Instal · lació

Comencem per la banalitat. L'aplicació està disponible i provada en tres plataformes: Linux, Windows i MacOS. Podeu descarregar l'instal·lador del sistema operatiu que us interessa el nostre lloc web. Per als usuaris de Linux és possible instal·lar paquet ràpid. Esperem de debò que la Microsoft Store i l'App Store s'hi arribin aviat (És necessari? Què en penseu?).

Escenari experimental

Hem escollit el següent escenari estàndard com a subjecte de prova:

• Inici de sessió: usuari - administrador, contrasenya - contrasenya
• afegir una nova entrada
• Comprovem que el registre s'ha afegit correctament

Ho farem a prova https://testmace-quick-start.herokuapp.com/. Això és normal json-server, perfecte per provar aquestes aplicacions. Acabem d'afegir autorització per testimoni a totes les rutes del servidor json i hem creat un mètode d'inici de sessió per rebre aquest testimoni. Anirem avançant progressivament, millorant progressivament el nostre projecte.

Creant un projecte i intentant crear una entitat sense autorització

Primer, creem un nou projecte (Dossier->Nou projecte). Si inicieu l'aplicació per primera vegada, s'obrirà automàticament un nou projecte. Primer, intentem fer una sol·licitud per crear un registre nou (en cas que la creació de registres estigui disponible sense autorització). Seleccioneu els elements del menú contextual del node Projecte Afegeix un node -> Sol·licitudPas. Estableix el nom del node a crear-publicació. Com a resultat, es crearà un nou node a l'arbre i s'obrirà una pestanya per a aquest node. Establim els següents paràmetres de sol·licitud:

• Tipus de sol·licitud: POST
• uRL: https://testmace-quick-start.herokuapp.com/posts
• Cos de la sol·licitud: json amb valor {"title": "New testmace quick start post"}
  Si ho heu fet tot correctament, la interfície es veurà així:

Tanmateix, si intentem atendre la sol·licitud, el servidor ens retornarà un codi 401 i sense autorització no obtindrem res en aquest servidor. Bé, en general, com era d'esperar).

Afegeix una sol·licitud d'autorització

Com ja s'ha esmentat, tenim un punt final POST /login, que pren json com a cos de sol·licitud de la forma: {"username": "<username>", "password": "<password>"}On username и password (de nou, a partir del paràgraf introductori anterior) tenen significats admin и password respectivament. En resposta, aquest punt final retorna json like {"token": "<token>"}. L'utilitzarem per a l'autorització. Anem a crear Sol·licitudPas node amb nom iniciar Sessió, actuarà com a avantpassat projecte node Mitjançant arrossegar i deixar anar, mou un node determinat de l'arbre més amunt que el node crear-publicació. Establim els paràmetres següents a la sol·licitud de nova creació:

• Tipus de sol·licitud: POST
• uRL: https://testmace-quick-start.herokuapp.com/login
• Cos de la sol·licitud: json amb valor {"username": "admin", "password": "password"}

Executem la sol·licitud i rebem el codi dos-centès amb el testimoni a la resposta. Alguna cosa com això:

Refactorització: eliminació de la duplicació de dominis

Fins ara, les sol·licituds no estan enllaçades en un sol script. Però aquest no és l'únic inconvenient. Si us fixeu bé, notareu que almenys el domini està duplicat en ambdues peticions. No és bó. És hora de refactoritzar aquesta part del futur script i les variables ens ajudaran amb això.

En una primera aproximació, les variables tenen el mateix paper que en altres eines i llenguatges de programació similars: eliminant la duplicació, augmentant la llegibilitat, etc. Podeu llegir més informació sobre les variables a la nostra documentació. En aquest cas, necessitarem variables d'usuari.

Definim una variable al nivell del node Projecte domain amb significat https://testmace-quick-start.herokuapp.com... Això requereix

• Obriu la pestanya amb aquest node i feu clic a la icona de la calculadora a la part superior dreta
• Fer clic a + AFEGIR VARIABLE
• Introduïu el nom i el valor de la variable
  En el nostre cas, el diàleg amb la variable afegida tindrà aquest aspecte:

D'ACORD. Ara, a causa de l'herència, podem utilitzar aquesta variable en descendents de qualsevol nivell de nidificació. En el nostre cas són nodes iniciar Sessió и crear-publicació. Per utilitzar una variable en un camp de text, cal escriure ${<variable_name>}. Per exemple, l'URL d'inici de sessió es converteix a ${domain}/login, respectivament per crear-publicació l'URL del node semblarà ${domain}/posts.

Així, guiats pel principi DRY, hem millorat lleugerament l'escenari.

Deseu el testimoni en una variable

Com que estem parlant de variables, ampliem una mica aquest tema. De moment, en cas d'iniciar sessió amb èxit, rebem del servidor un testimoni d'autorització, que necessitarem en posteriors peticions. Desem aquest testimoni en una variable. Perquè el valor de la variable es determinarà durant l'execució de l'script, utilitzem un mecanisme especial per a això: variables dinàmiques.

Primer, realitzem una sol·licitud d'inici de sessió. A la pestanya Analitzat resposta, moveu el cursor sobre el testimoni i al menú contextual (que s'anomena amb el botó dret del ratolí o fent clic al botó ...) seleccioneu l'element Assigna a variable. Apareixerà un diàleg amb els camps següents:

• Camí — quina part de la resposta es pren (en el nostre cas ho és body.token)
• Valor actual — quin valor es troba al llarg del camí (en el nostre cas, aquest és el valor del testimoni)
• Nom de la variable — nom de la variable on Valor actual es conservarà. En el nostre cas serà així token
• Node — en quin dels avantpassats es crearà la variable Nom de la variable. Seleccionem Projecte

El diàleg completat és el següent:

Ara cada vegada que s'executa el node iniciar Sessió variable dinàmica token s'actualitzarà amb el nou valor de la resposta. I aquesta variable s'emmagatzemarà a projecte node i, gràcies a l'herència, estarà a disposició dels descendents.

Per accedir a variables dinàmiques, heu d'utilitzar variable incorporada $dynamicVar. Per exemple, per accedir a un testimoni emmagatzemat, heu de trucar ${$dynamicVar.token}.

Passem el testimoni d'autorització a les sol·licituds

En els passos anteriors hem rebut el testimoni d'autorització i tot el que hem de fer és afegir una capçalera Authorization amb significat Bearer <tokenValue> en totes les sol·licituds que requereixen autorització, inclòs crear-publicació. Hi ha diverses maneres de fer-ho:

1. Copieu manualment el testimoni i afegiu una capçalera d'autorització a les sol·licituds d'interès. El mètode funciona, però el seu ús es limita només a les peticions del tipus "fet i llençat". No apte per a l'execució repetida d'scripts
2. Utilitzeu la funcionalitat autorització.
3. Utilitzeu capçaleres predeterminades

L'ús del segon mètode sembla obvi, però en el context d'aquest article, aquest enfocament és... poc interessant. Bé, de veritat: el mecanisme d'autorització més menys us és familiar d'altres eines (encara que tinguem coses com autorització herència) i és poc probable que plantegi preguntes.

Una altra cosa són les capçaleres predeterminades! En poques paraules, les capçaleres predeterminades són capçaleres HTTP heretades que s'afegeixen a la sol·licitud de manera predeterminada, tret que es desactivin explícitament. Amb aquesta funcionalitat, podeu, per exemple, implementar una autorització personalitzada o simplement desfer-vos de la duplicació dels scripts. Utilitzem aquesta funció per passar un testimoni a les capçaleres.

Anteriorment, amb prudència vam desar el testimoni en una variable dinàmica $dynamicVar.token a nivell de node Projecte. Només queda fer el següent:

1. Definiu el títol per defecte Authorization amb significat Bearer ${$dynamicVar.token} a nivell de node Projecte. Per fer-ho, a la interfície Projecte del node cal obrir un diàleg amb els encapçalaments per defecte (botó Capçaleres a la cantonada superior dreta) i afegiu-hi un títol corresponent. El diàleg amb els valors emplenats tindrà aquest aspecte:
   
2. Desactiveu aquesta capçalera des de la sol·licitud d'inici de sessió. Això és comprensible: en el moment d'iniciar sessió, encara no tenim cap testimoni i l'instal·larem amb aquesta sol·licitud. Per tant, a la interfície d'inici de sessió de la sol·licitud a la pestanya Capçaleres a la zona de Heretat desmarqueu la capçalera Autorització.

Això és tot. Ara la capçalera d'autorització s'afegirà a totes les sol·licituds que siguin fills del node Projecte, excepte al node d'inici de sessió. Resulta que en aquesta fase ja tenim un guió a punt i només ens queda llançar-lo. Podeu executar l'script seleccionant Correr al menú contextual del node Projecte.

Comprovació de la correcció de la creació de la publicació

En aquesta etapa, el nostre script pot iniciar sessió i, mitjançant un testimoni d'autorització, crear una publicació. Tanmateix, ens hem d'assegurar que la publicació de nova creació tingui el nom correcte. És a dir, en essència, només queda fer el següent:

• Envieu una sol·licitud per rebre una publicació per identificador,
• Comproveu que el nom rebut del servidor coincideixi amb el nom enviat en crear la publicació

Vegem el primer pas. Atès que el valor d'identificador es determina durant l'execució de l'script, cal que creeu una variable dinàmica (anomenarem-la postId) des del node crear-publicació a nivell de node Projecte. Ja sabem com fer-ho, només cal que consulteu l'apartat Deseu el testimoni en una variable. Només queda crear una sol·licitud per rebre una publicació amb aquest identificador. Per fer-ho, creem un RequestStep get-post amb els següents paràmetres:

• Tipus de sol·licitud: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Per implementar el segon pas, ens hem de familiaritzar Afirmació nus. Un node d'asserció és un node que us permet escriure comprovacions per a sol·licituds específiques. Cada node d'asserció pot contenir diverses assercions (comprovacions). Podeu llegir més sobre tot tipus d'afirmacions al nostre documentació. Farem servir Compare afirmació amb l'operador equal. Hi ha diverses maneres de crear afirmacions:

1. Llarg. Creeu manualment un node Assertion des del menú contextual del node RequestStep. Al node Asserció creat, afegiu l'afirmació d'interès i ompliu els camps.
2. Ràpid. Creeu un node d'asserció juntament amb una asserció de la resposta del node RequestStep mitjançant el menú contextual

Utilitzem el segon mètode. Així serà el nostre cas.

Per als que no ho entenguin, aquí teniu el que està passant:

1. Feu una sol·licitud al node get-post
2. A la pestanya Analitzat respon, crida al menú contextual i selecciona Crea una afirmació -> comparar -> igual

Enhorabona, hem creat la nostra primera prova! Simple, no? Ara podeu executar l'script completament i gaudir del resultat. Només queda refactoritzar-lo una mica i treure'l title en una variable separada. Però us ho deixarem com a deures)

Conclusió

En aquesta guia, hem creat un escenari complet i, al mateix temps, hem revisat algunes de les característiques del nostre producte. Per descomptat, no hem utilitzat totes les funcionalitats i en els articles següents oferirem una visió general detallada de les capacitats de TestMace. Estigueu atents!

PD Per a aquells que tinguin mandra de reproduir tots els passos, ho hem enregistrat amablement repositori amb el projecte de l'article. Podeu obrir-lo amb Dossier -> Projecte obert i seleccioneu la carpeta Projecte.

Font: www.habr.com