{"id":54188,"date":"2019-12-20T00:00:00","date_gmt":"2019-12-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/chem-testmace-luchshe-postman"},"modified":"2020-02-18T14:02:10","modified_gmt":"2020-02-18T11:02:10","slug":"chem-testmace-luchshe-postman","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/chem-testmace-luchshe-postman","title":{"rendered":"Perch\u00e9 TestMace \u00e8 migliore di Postman","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Perch\u00e9<\/p>\n

<\/p>\n

Ciao a tutti, qui \u00e8 TestMace<\/a><\/noindex>! Forse molti di voi ci conoscono da noi<\/a><\/noindex> le precedenti<\/a><\/noindex> articoli<\/a><\/noindex>. Per quelli che si stanno appena collegando: stiamo sviluppando un IDE per lavorare con l'API TestMace. La domanda pi\u00f9 frequente quando si confronta TestMace con prodotti concorrenti \u00e8 \u2014 «Cosa vi distingue da Postman?». Abbiamo deciso che \u00e8 ora di dare una risposta esaustiva a questa domanda. Qui di seguito abbiamo elencato i nostri vantaggi rispetto a Postman<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Divisione in nodi<\/h2>\n

<\/p>\n

Se lavori con Postman, sai che l'interfaccia della richiesta contiene tutte le funzionalit\u00e0 necessarie. Ci sono script, test e, fondamentalmente, le richieste stesse. Questo semplifica il lavoro per i principianti, ma con scenari pi\u00f9 complessi, questo approccio non \u00e8 flessibile. Cosa succede se vuoi creare pi\u00f9 richieste e fare aggregazione su di esse? Cosa succede se desideri eseguire uno script senza richiesta o pi\u00f9 script logicamente separati uno dopo l'altro? Infine, sarebbe opportuno separare i test dagli script utilitari comuni. Inoltre, l'approccio «aggiungiamo tutte le funzionalit\u00e0 in un nodo» non \u00e8 scalabile: l'interfaccia diventa rapidamente sovraccaricata.<\/p>\n

<\/p>\n

TestMace inizialmente divide tutte le funzionalit\u00e0 in diversi tipi di nodi. Vuoi fare una richiesta? Ecco un request step<\/a><\/noindex> nodo. Vuoi scrivere uno script? Ecco un script<\/a><\/noindex> nodo. Hai bisogno di test? Prego \u2014 Assertion<\/a><\/noindex> nodo. Ah gi\u00e0, puoi anche avvolgere tutto questo in un folder<\/a><\/noindex> nodo. E tutto ci\u00f2 \u00e8 facilmente combinabile tra loro. Questo approccio non solo \u00e8 molto flessibile, ma, seguendo il principio della singola responsabilit\u00e0, consente di utilizzare solo ci\u00f2 di cui hai realmente bisogno in quel momento. Perch\u00e9 dovrei avere script e test se voglio semplicemente fare una richiesta?<\/p>\n

<\/p>\n

Formato leggibile dall'uomo del progetto<\/h2>\n

<\/p>\n

Tra TestMace e Postman c'\u00e8 una differenza concettuale nel modo di archiviare. In Postman tutte le richieste sono memorizzate da qualche parte in un'archiviazione locale. Se \u00e8 necessario condividere le richieste tra pi\u00f9 utenti, \u00e8 necessario utilizzare la sincronizzazione integrata. In realt\u00e0, questo \u00e8 un approccio comunemente accettato, ma non privo di difetti. Che dire della sicurezza dei dati? Infatti, la politica di alcune aziende potrebbe non consentire di memorizzare i dati presso terzi. Tuttavia, riteniamo che TestMace possa offrire qualcosa di meglio! E il nome di questo miglioramento \u00e8 «formato di progetto leggibile dall'uomo».<\/p>\n

<\/p>\n

Iniziamo col dire che in TestMace esiste fondamentalmente l'entit\u00e0 \"progetto\". L'applicazione \u00e8 stata originariamente sviluppata con l'obiettivo di memorizzare i progetti nei sistemi di controllo versione: la struttura dell'albero di progetto si proietta praticamente uno a uno sulla struttura delle cartelle, utilizzando il formato di memorizzazione yaml (senza parentesi e virgole superflue), e la rappresentazione file di ogni nodo \u00e8 descritta in dettaglio nella documentazione con commenti. Ma nella maggior parte dei casi non sar\u00e0 necessario dare un'occhiata a questa \u2014 tutti i nomi dei campi hanno denominazioni logiche. <\/p>\n

<\/p>\n

Cosa offre questo all'utente? Permette di modificare in maniera molto flessibile il workflow del team, adottando approcci familiari. Ad esempio, gli sviluppatori possono memorizzare il progetto nello stesso repository del backend. Nei rami, oltre a modificare direttamente la base di codice, lo sviluppatore pu\u00f2 correggere gli scenari di richieste esistenti e i test. Dopo aver registrato le modifiche nel repository (git, svn, mercurial \u2014 quello che preferisci), CI (il tuo preferito, non imposto da nessuno) avvia la nostra utility da console testmace-cli<\/a><\/noindex>, e il rapporto generato dopo l'esecuzione (ad esempio, in formato junit, che \u00e8 anche supportato in testmace-cli) viene inviato al sistema corrispondente. E anche la questione di cui sopra riguardante la sicurezza non \u00e8 pi\u00f9 un problema.<\/p>\n

<\/p>\n

Come puoi vedere, TestMace non impone il suo ecosistema e paradigma. Invece, si integra facilmente nei processi gi\u00e0 consolidati.<\/p>\n

<\/p>\n

Variabili dinamiche<\/h2>\n

<\/p>\n

TestMace segue il concetto di no-code: se un problema pu\u00f2 essere risolto senza l'uso di codice, ci impegniamo a offrire tale opportunit\u00e0. Lavorare con le variabili \u00e8 proprio quella funzionalit\u00e0 nella quale la maggior parte delle volte \u00e8 possibile fare a meno della programmazione.<\/p>\n

<\/p>\n

Esempio: abbiamo ricevuto una risposta dal server e vogliamo salvare una parte della risposta in una variabile. In Postman scriveremmo nello script di test (che di per s\u00e9 \u00e8 strano) qualcosa del tipo:<\/p>\n

<\/p>\n

var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", jsonData.data);<\/code><\/pre>\n
<\/p>\n
Ma secondo noi, scrivere uno script per uno scenario cos\u00ec semplice e frequentemente utilizzato appare eccessivo. Pertanto, in TestMace \u00e8 possibile assegnare una parte della risposta a una variabile utilizzando l'interfaccia grafica. Guarda quanto \u00e8 semplice:<\/p>\n
<\/p>\n
\"Perch\u00e9<\/p>\n
<\/p>\n
E ora, ad ogni richiesta, questa variabile dinamica verr\u00e0 aggiornata. Ma potreste obiettare, sostenendo che l'approccio di Postman \u00e8 pi\u00f9 flessibile e consente non solo di effettuare un'assegnazione, ma anche di eseguire una certa pre-elaborazione. Ecco come si pu\u00f2 modificare l'esempio precedente:<\/p>\n
<\/p>\n
var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", CryptoJS.MD5(jsonData.data));<\/code><\/pre>\n
<\/p>\n
Beh, per questo in TestMace c'\u00e8 script<\/a><\/noindex> un nodo che copre questo scenario. Per riprodurre il caso precedente, ma gi\u00e0 nell'implementazione di TestMace, \u00e8 necessario creare un nodo script dopo la richiesta e utilizzare il seguente codice come script:<\/p>\n
<\/p>\n
const data = tm.currentNode.prev.response.body.data;\ntm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));<\/code><\/pre>\n
<\/p>\n
Come vedete, la composizione dei nodi ha funzionato bene anche qui. E per un caso cos\u00ec semplice, come descritto sopra, potete semplicemente assegnare l'espressione ${crypto.MD5($response.data)}<\/code> a una variabile creata tramite l'interfaccia grafica!<\/p>\n
<\/p>\n
Creazione di test tramite GUI<\/h2>\n
<\/p>\n
Postman consente di creare test scrivendo script (nel caso di Postman, si tratta di JavaScript). Questo approccio ha solo vantaggi: flessibilit\u00e0 praticamente illimitata, presenza di soluzioni pronte, ecc.<\/p>\n
<\/p>\n
Tuttavia, le realt\u00e0 sono spesso tali (non siamo noi, \u00e8 la vita) che il tester non ha competenze di programmazione, e si vorrebbe gi\u00e0 contribuire al team. Per questi casi, seguendo il concetto no-code, TestMace consente di creare test semplici tramite l'interfaccia grafica, senza ricorrere alla scrittura di script. Ecco, ad esempio, come appare il processo di creazione di un test che confronta valori per uguaglianza:<\/p>\n
<\/p>\n
\"Perch\u00e9<\/p>\n
<\/p>\n
Tuttavia, la creazione di test nell'editor grafico non esclude la possibilit\u00e0 di scrivere test nel codice<\/a><\/noindex>. Qui ci sono tutte le stesse librerie che nel nodo script, e chai<\/a><\/noindex> per scrivere i test.<\/p>\n
<\/p>\n
Altre differenze<\/h2>\n
<\/p>\n