Ciao a tutti. Stiamo lentamente uscendo dall'ombra e continuiamo la nostra serie di articoli sul nostro prodotto. Dopo quello precedente l'articolo introduttivo, abbiamo ricevuto molti feedback (per lo più positivi), suggerimenti e segnalazioni di bug. Oggi vi mostreremo TestMace il nostro applicativo in azione, dove potrete apprezzare alcune delle funzionalità del nostro software. Per un'immersione più completa, vi consiglio di consultare la nostra documentazione all'indirizzo http://docs-ru.testmace.com. Quindi, cominciamo!

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 di vostro interesse da il nostro sito. Per gli utilizzatori di Linux, è disponibile l'installazione del pacchetto snap.Ci auguriamo vivamente di riuscire a raggiungere presto anche Microsoft Store e App Store (ma è necessario? Cosa ne pensate?).

Scenario di test

Come scenario di prova abbiamo scelto il seguente scenario standard:

• effettueremo il login: utente — admin, password — password
• aggiungeremo una nuova registrazione
• verificheremo l'aggiunta corretta della registrazione

Testeremo su https://testmace-quick-start.herokuapp.com/. È un comune json-server, perfetto per testare simili applicazioni. Abbiamo appena aggiunto l'autenticazione tramite token a tutte le route del json-server e abbiamo implementato 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 autenticazione

Iniziamo creando un nuovo progetto (File->Nuovo progetto). Se stai avviando l'applicazione per la prima volta, il nuovo progetto si aprirà automaticamente. Proviamo prima di tutto a fare una richiesta per creare una nuova registrazione (magari la creazione di registrazioni è disponibile senza autenticazione). Seleziona nel menu contestuale del nodo Project le voci 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 questo nodo. Impostiamo i seguenti parametri per la richiesta:

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

Tuttavia, se proviamo a effettuare la richiesta, il server restituirà un codice 401 e senza autenticazione non ci sarà nulla da fare su questo server. Beh, in effetti, era prevedibile).

Aggiungiamo la richiesta di autenticazione

Come già detto, abbiamo un endpoint POST /login, che accetta come corpo della richiesta un JSON del tipo: {"username": "", "password": ""}, dove username e password (ancora una volta, dai riferimenti precedenti) hanno valori admin e password rispettivamente. In risposta, questo endpoint restituisce un JSON del tipo {"token": ""}. Utilizzeremo questo per l'autenticazione. Creeremo RequestStep un nodo con il nome accesso, il nodo genitore sarà Progetto questo nodo. Con il drag-and-drop, sposta questo nodo nella struttura al di sopra del 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 osserviamo attentamente, possiamo notare che almeno il dominio è duplicato in entrambe le richieste. Non è ideale. È tempo di rifattorizzare questa parte del futuro scenario e le variabili ci aiuteranno in questo.

In linea di massima, le variabili svolgono la stessa funzione che hanno in altri strumenti e linguaggi di programmazione simili — eliminare le duplicazioni, migliorare la leggibilità, ecc. Puoi leggere di più sulle variabili in nostra documentazione. In questo caso, abbiamo bisogno di variabili personalizzate.

Definiamo a livello del nodo Project una variabile dominio con il valore https://testmace-quick-start.herokuapp.com. Per fare ciò, è necessario

• Aprire la scheda di questo nodo e cliccare sull'icona della calcolatrice in alto a destra
• Cliccare 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 discendenti a qualsiasi livello di annidamento. Nel nostro caso sono i nodi accesso 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 apparirà come ${domain}/posts.

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

Salviamo il token nella variabile

Dal momento che stiamo parlando di variabili, approfondiamo un po' questo argomento. Al momento, in caso di accesso riuscito, riceviamo dal server un token di autorizzazione, che sarà necessario per le richieste successive. Salviamo questo token in una variabile. Poiché il valore della variabile sarà determinato durante l'esecuzione dello script, useremo un meccanismo speciale — variabili dinamiche.

Per iniziare, eseguiamo una richiesta di accesso. Nella scheda Parsed del risposta, posiziona il cursore sul token e nel menu contestuale (che appare con il tasto destro del mouse o premendo il pulsante …) seleziona l'opzione Assegna alla variabile. Apparirà una finestra di dialogo con i seguenti campi:

• Path — quale parte della risposta viene presa (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à il token
• Node — in quale genitore verrà creata la variabile Nome variabile. Selezioniamo Project

La finestra di dialogo compilata appare come segue:

Ora, ad ogni esecuzione del nodo accesso la variabile dinamica il token verrà aggiornata con il nuovo valore dalla risposta. E questa variabile sarà memorizzata in Progetto e grazie all'ereditarietà sarà accessibile ai discendenti.

Per accedere alle variabili dinamiche, è necessario utilizzare una 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 ciò che dobbiamo fare è aggiungere l'intestazione Authorization con il valore Bearer in tutte le richieste che richiedono autorizzazione, comprese create-post. Ci sono diversi modi per farlo:

1. Copiare manualmente il token e aggiungere l'intestazione di autorizzazione alle richieste di interesse. Questo metodo funziona, ma è limitato solo a richieste di tipo 'l'ho fatto e l'ho scartato'. Non è adatto per l'esecuzione ripetuta di scenari.
2. Utilizzare la funzionalità autenticazione.
3. Usa intestazioni predefinite

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

Un altro discorso sui titoli per impostazione predefinita! In breve, i titoli per impostazione predefinita sono intestazioni HTTP ereditate, che vengono aggiunte automaticamente alla richiesta se non disattivate esplicitamente. Questa funzionalità può essere utilizzata, ad esempio, per implementare un'autenticazione personalizzata o semplicemente per eliminare la duplicazione in scenari. Applichiamo questa funzione per passare il token nelle intestazioni.

In precedenza, abbiamo saggiamente salvato il token in una variabile dinamica $dynamicVar.token a livello del nodo Project. Rimane da fare quanto segue:

1. Definire l'intestazione predefinita Authorization con il valore Bearer ${$dynamicVar.token} a livello del nodo Project. Per fare ciò, nell'interfaccia del nodo Project, è necessario aprire il dialogo con le intestazioni predefinite (il pulsante Headers nell'angolo in alto a destra) e aggiungere l'intestazione corrispondente. Il dialogo con i valori compilati apparirà come segue:
   
2. Disattivare questa intestazione dalla richiesta di login. È ovvio: al momento del login non abbiamo ancora il token e con questa richiesta lo stabiliamo. Pertanto, nell'interfaccia della richiesta di login, nella scheda Headers nell'area Inherited togliamo il segno di spunta dall'intestazione Authorization.

Questo è tutto. Ora l'intestazione di autorizzazione verrà aggiunta a tutte le richieste che sono discendenti del nodo Project, escluso il nodo login. Quindi, a questo punto, abbiamo già uno script pronto e ci resta solo da eseguirlo. È possibile avviare lo script selezionando l'opzione Esegui dal menu contestuale del nodo Project.

Controlliamo la correttezza della creazione del post

A questo punto, il nostro script è in grado di effettuare il login e, utilizzando il token di autorizzazione, creare un post. Tuttavia, dobbiamo assicurarci che il nuovo post abbia un nome corretto. In pratica, resta da fare quanto segue:

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

Esaminiamo il primo passo. Poiché il valore 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 fare ciò lo sappiamo già, basta fare riferimento alla sezione Salviamo il token nella variabile. Resta solo da creare una richiesta per ottenere il post con questo id. Per fare ciò, creiamo un RequestStep get-post con i seguenti parametri:

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

Per realizzare il secondo passo, dobbiamo familiarizzarci con Assertion il nodo. Il nodo Assertion è un nodo che consente di scrivere verifiche su determinate richieste. Ogni nodo Assertion può contenere più affermazioni (verifiche). Ulteriori informazioni su tutti i tipi di assertion possono essere trovate nel nostro documentazione. Useremo Compare assertion con l'operatore equal. Ci sono diversi modi per creare le assertion:

1. Lento. Creare manualmente un nodo Assertion dal menu contestuale del nodo RequestStep. Nel nodo Assertion creato, aggiungere l'assertion desiderato e compilare 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à nel nostro caso.

Per coloro che non hanno compreso, ecco cosa succede:

1. Fare una richiesta nel nodo get-post
2. Nella scheda Parsed risposta, richiamare il menu contestuale e selezionare Create assertion -> Compare -> Equal

Congratulazioni, abbiamo creato il nostro primo test! Facile, vero? Ora puoi eseguire completamente lo scenario e goderti il risultato. Resta solo da rifattorizzare e spostare titolo in una variabile separata. Ma lasceremo questo a voi come compito a casa :)

Conclusione

In questa guida abbiamo creato uno scenario completo e abbiamo anche esaminato alcune delle funzionalità del nostro prodotto. Ovviamente, non abbiamo sfruttato tutte le funzioni e nei prossimi articoli faremo una panoramica dettagliata delle possibilità di TestMace. Seguite gli aggiornamenti!

P.S. Per coloro che non vogliono riprodurre tutti i passaggi, abbiamo gentilmente preparato repository il progetto dell'articolo. Può essere aperto tramite File -> Open project e selezionare la cartella Project.

Fonte: habr.com