Ciao a tutti. Stiamo lentamente uscendo dall'ombra e continuiamo la nostra serie di articoli sul nostro prodotto. Dopo precedente l'articolo introduttivo, abbiamo ricevuto numerosi feedback (principalmente positivi), suggerimenti e report di bug. Oggi vi mostreremo TestMace in azione e voi potrete apprezzare alcune funzionalità della nostra applicazione. Per un'immersione più completa, vi consiglio di consultare la nostra documentazione all'indirizzo http://docs-ru.testmace.com. Dunque, partiamo!

Installazione

Iniziamo con una banalità. L'applicazione è disponibile e realmente testabile su tre piattaforme: Linux, Windows, MacOS. Potete scaricare il programma di installazione per il sistema operativo desiderato da il nostro sito. Per gli utenti Linux, c'è la possibilità di installare il pacchetto snap. Speriamo davvero che presto si arrivi al Microsoft Store e all'App Store (ma è davvero necessario? Che ne pensate?).

Scenario di prova

Come soggetto di prova, abbiamo scelto il seguente scenario standard:

• accediamo: utente — admin, password — password
• aggiungiamo una nuova voce
• verifichiamo l'aggiunta corretta della voce

Testeremo su https://testmace-quick-start.herokuapp.com/. Si tratta di un normale json-server, perfetto per testare applicazioni simili. Abbiamo solo aggiunto l'autenticazione tramite token a tutte le rotte del json-server e creato il metodo login per ottenere questo token. Procederemo passo dopo passo, migliorando gradualmente il nostro progetto.

Creazione del progetto e tentativo di creare un'entità senza autorizzazione

Iniziamo creando un nuovo progetto (File->Nuovo progetto). Se apri l'applicazione per la prima volta, il nuovo progetto si aprirà automaticamente. Proviamo prima a fare una richiesta per creare una nuova voce (magari la creazione di voci è disponibile senza autorizzazione). Selezionate nel menu contestuale del nodo Project le opzioni Aggiungi nodo -> RequestStep. Come nome del nodo impostiamo create-post. Di conseguenza, verrà creato un nuovo nodo nell'albero e si aprirà la scheda di quel nodo. Impostiamo i seguenti parametri della richiesta:

• Tipo di richiesta: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Corpo della richiesta: json con il valore {"title": "New testmace quick start post"}
  Se hai fatto tutto correttamente, l'interfaccia apparirà come segue:

Tuttavia, se proviamo a eseguire la richiesta, il server restituirà un codice 401 e senza autorizzazione non riusciremo a fare nulla su questo server. Beh, in effetti, era prevedibile).

Aggiungiamo una richiesta di autorizzazione

Come già detto, abbiamo un endpoint POST /login, che accetta come corpo della richiesta un json del tipo: {"username": "", "password": ""}, dove username e password (di nuovo, come accennato in precedenza) hanno significato admin e password di conseguenza. In risposta, questo endpoint restituisce un json di tipo {"token": ""}. Lo useremo per l'autenticazione. Creiamo RequestStep un nodo di nome login, come genitore avremo Progetto un nodo. Usa il drag-and-drop per spostare questo nodo nella gerarchia sopra il nodo create-post. Impostiamo i seguenti parametri per la richiesta appena creata:

• Tipo di richiesta: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Corpo della richiesta: json con il valore {"username": "admin", "password": "password"}

Eseguiamo la richiesta e riceviamo un codice 200 con il token nella risposta. Ecco come:

Refactoring: rimuoviamo la duplicazione del dominio

Finora le richieste non sono collegate in un unico scenario. Ma questo non è l'unico difetto. Se si osserva attentamente, si può notare che almeno il dominio è duplicato in entrambe le richieste. Non è ideale. È tempo di refactoring di questa parte dello scenario futuro e questo ci aiuteranno le variabili.

In prima approssimazione, le variabili svolgono la stessa funzione che in altri strumenti e linguaggi di programmazione simili: eliminazione della duplicazione, miglioramento della leggibilità, ecc. Puoi leggere di più sulle variabili in documentazione. In questo caso avremo bisogno di variabili utente.

Definiamo a livello di Progetti la variabile domain con valore https://testmace-quick-start.herokuapp.com. Per fare questo, è necessario

• Aprire la scheda con questo nodo e fare clic sull'icona della calcolatrice in alto a destra
• Fare clic su + AGGIUNGI VARIABILE
• Inserire il nome e il valore della variabile
  Nel nostro caso, la finestra di dialogo con la variabile aggiunta apparirà come segue:

OK. Ora grazie all'ereditarietà possiamo utilizzare questa variabile nei nodi discendenti a qualsiasi livello di annidamento. Nel nostro caso, sono i nodi login e create-post. Per utilizzare la variabile nel campo di testo, è necessario scrivere ${}. Ad esempio, l'url per il login si trasforma in ${domain}/login, di conseguenza per create-post il nodo l'url sarà ${domain}/posts.

In questo modo, seguendo il principio DRY, abbiamo migliorato leggermente lo scenario.

Salviamo il token nella variabile

Dato che abbiamo parlato di variabili, approfondiamo un po' questo argomento. Al momento, nel caso di login riuscito, otteniamo dal server un token di autorizzazione che ci servirà nelle richieste successive. Salviamo questo token in una variabile. Poiché il valore della variabile verrà determinato durante l'esecuzione dello scenario, utilizziamo un meccanismo speciale per questo — variabili dinamiche.

Iniziamo con una richiesta di login. Nella scheda Analizzato posiziona il cursore sul token e nel menu contestuale (che può essere aperto cliccando con il tasto destro del mouse o premendo il pulsante …) seleziona l'opzione Assegna a variabile. Apparirà una finestra di dialogo con i seguenti campi:

• Path — quale parte della risposta viene prelevata (in questo caso è body.token)
• Valore attuale — quale valore si trova nel percorso Path (in questo caso è il valore del token)
• Nome variabile — il nome della variabile in cui Valore attuale verrà salvato. In questo caso sarà token
• Node — in quale antenato verrà creata la variabile Nome variabile. Scegliamo Project

La finestra di dialogo compilata appare come segue:

Ora, ad ogni esecuzione del nodo login la variabile dinamica token verrà aggiornata con il nuovo valore dalla risposta. E questa variabile sarà memorizzata nel Progetto nodo e grazie all'ereditarietà sarà disponibile per le generazioni successive.

Per accedere alle variabili dinamiche, è necessario utilizzare la variabile incorporata $dynamicVar. Ad esempio, per accedere al token salvato, è necessario chiamare ${$dynamicVar.token}.

Passiamo il token di autorizzazione nelle richieste

Nei passaggi precedenti abbiamo ottenuto il token di autorizzazione e tutto quello che dobbiamo fare è aggiungere l'intestazione Authorization con valore Bearer in tutte le richieste che richiedono autorizzazione, inclusa create-post. Ci sono diversi metodi per farlo:

1. Copiare manualmente il token e aggiungere l'intestazione di autorizzazione alle richieste interessate. Questo metodo funziona, tuttavia il suo utilizzo è limitato solo a richieste del tipo ‘fatto e buttato via’. Non è adatto per l'esecuzione ripetuta di script.
2. Utilizzare la funzionalità di autorizzazione.
3. di utilizzare intestazioni predefinite

L'uso del secondo metodo sembra ovvio, ma nel contesto di questo articolo tale approccio… non è interessante. Be', davvero: il meccanismo delle autorizzazioni è più o meno conosciuto per voi da altri strumenti (anche se abbiamo cose come ereditarietà delle autorizzazioni) e difficilmente susciterà domande.

Un'altra questione sono gli header di default! In poche parole, gli header di default sono gli header HTTP ereditati che vengono aggiunti per impostazione predefinita alla richiesta, a meno che non vengano esplicitamente disabilitati. Con questa funzionalità, ad esempio, è possibile implementare un'autenticazione personalizzata o semplicemente eliminare la duplicazione negli scenari. Applichiamo questa funzionalità per inoltrare il token negli header.

In precedenza, abbiamo preservato il token in una variabile dinamica $dynamicVar.token a livello del nodo Project. Ora dobbiamo fare quanto segue:

1. Definire l'header di default Authorization con valore Bearer ${$dynamicVar.token} a livello del nodo Project. Per fare ciò, nell'interfaccia del nodo Project è necessario aprire il dialogo con gli header di default (pulsante Headers nell'angolo in alto a destra) e aggiungere l'header corrispondente. Il dialogo con i valori popolati apparirà come segue:
   
2. Disattivare questo header dalla richiesta di login. È chiaro: al momento del login non abbiamo ancora il token e con questa richiesta lo stiamo effettivamente impostando. Pertanto, nell'interfaccia della richiesta di login, nella scheda Headers nell'area Inherited dobbiamo deselezionare l'header Authorization.

Detto questo, ora l'header di autorizzazione verrà aggiunto a tutte le richieste che sono figli del nodo Project, eccetto il nodo di login. Quindi, a questo punto, abbiamo già uno script pronto e non ci resta che avviarlo. È possibile avviare lo script selezionando l'opzione Esegui nel menu contestuale del nodo Project.

Verifichiamo la correttezza della creazione del post

A questo punto, il nostro script può effettuare il login e, utilizzando il token di autorizzazione, creare un post. Tuttavia, dobbiamo assicurarci che il post appena creato abbia un nome corretto. In altre parole, dobbiamo fare quanto segue:

• Inviare una richiesta per ottenere il post per id,
• Verificare che il nome ricevuto dal server corrisponda al nome fornito durante la creazione del post

Consideriamo il primo passo. Poiché il valore di id viene determinato durante l'esecuzione dello script, è necessario creare una variabile dinamica (chiamiamola postId) dal nodo create-post a livello del nodo Project. Come farlo già sappiamo, è sufficiente fare riferimento alla sezione Salviamo il token nella variabile. Ora resta solo da creare una richiesta per ottenere il post per tale id. Per fare ciò, creeremo un RequestStep get-post con i seguenti parametri:

• Tipo di richiesta: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Per implementare il secondo passo, è necessario familiarizzare con Assertion il nodo. Il nodo Assertion è un nodo che consente di scrivere verifiche su determinate richieste. Ogni nodo Assertion può contenere diverse affermazioni (verifiche). Puoi leggere di più su tutti i tipi di assertion nel nostro documentazione. Useremo Compare assertion con l'operatore equal. Ci sono diversi modi per creare le assertion:

1. Lungo. Creare manualmente un nodo Assertion dal menu contestuale del nodo RequestStep. Nel nodo Assertion creato, aggiungere l'assertion desiderato e riempire i campi.
2. Veloce. Creare un nodo Assertion insieme all'assertion dalla risposta del nodo RequestStep utilizzando il menu contestuale

Utilizzeremo il secondo metodo. Ecco come apparirà per il nostro caso.

Per coloro che non hanno capito, ecco cosa succede:

1. Fare una richiesta nel nodo get-post
2. Nella scheda Analizzato nell risposta per far apparire il menu contestuale e selezionare Create assertion -> Compare -> Equal

Congratulazioni, abbiamo creato il nostro primo test! Facile, vero? Adesso puoi eseguire lo scenario completamente e goderti il risultato. Rimane solo un po' da rifattorizzare e portare title in una variabile separata. Ma questo lo lasciamo a te come compito a casa)

Conclusione

In questa guida abbiamo creato uno scenario completo e nel contempo esaminato alcune funzionalità del nostro prodotto. Ovviamente, non abbiamo utilizzato tutte le funzionalità e nei prossimi articoli faremo un'analisi dettagliata delle capacità di TestMace. Restate sintonizzati per gli aggiornamenti!

P.S. Per coloro che non vogliono ripetere tutti i passaggi, abbiamo gentilmente preparato repository con il progetto dell'articolo. Puoi aprirlo tramite File -> Open project e selezionare la cartella Project.

Fonte: habr.com