{"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\/novosti-interneta\/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>! Molti di voi potrebbero conoscerci da nostri<\/a><\/noindex> precedenti<\/a><\/noindex> articoli<\/a><\/noindex>. Per chi si \u00e8 appena collegato: stiamo sviluppando un IDE per lavorare con l'API TestMace. La domanda pi\u00f9 comune quando si confronta TestMace con prodotti concorrenti \u00e8: \u00abQual \u00e8 la vostra differenza rispetto a Postman?\u00bb. Abbiamo deciso che era ora di fornire una risposta dettagliata a questa domanda. Di seguito abbiamo elencato i nostri vantaggi rispetto a Postman<\/a><\/noindex>.<\/p>\n

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

Separazione in nodi<\/h2>\n

<\/p>\n

Se lavori con Postman, sai che l'interfaccia della richiesta contiene tutte le funzionalit\u00e0 necessarie. Qui ci sono script, test e, in effetti, le richieste stesse. Questo semplifica il lavoro per i principianti, ma con scenari complessi questo approccio non \u00e8 flessibile. Cosa succede se vuoi creare pi\u00f9 richieste e fare aggregazioni su di esse? Cosa succede se desideri eseguire uno script senza richiesta o eseguire pi\u00f9 script logicamente separati di fila? Dopotutto, sarebbe utile separare i test dagli script utilitari comuni. Inoltre, l'approccio di \u00abaggiungere tutte le funzionalit\u00e0 in un nodo\u00bb non \u00e8 scalabile \u2014 l'interfaccia diventa rapidamente sovraccarica.<\/p>\n

<\/p>\n

TestMace separa fin dall'inizio tutte le funzionalit\u00e0 in diversi tipi di nodi. Vuoi fare una richiesta? Ecco a te richiesta passo<\/a><\/noindex> nodo. Vuoi scrivere uno script? Ecco a te script<\/a><\/noindex> nodo. Hai bisogno di test? Prego \u2014 Assertion<\/a><\/noindex> nodo. Ah, puoi anche avvolgere tutto questo in cartella<\/a><\/noindex> nodo. E tutto ci\u00f2 si combina facilmente. Questo approccio non solo \u00e8 molto flessibile, ma, in conformit\u00e0 con il principio di responsabilit\u00e0 unica, consente di utilizzare solo ci\u00f2 di cui hai davvero bisogno in quel momento. Perch\u00e9 dovrei avere script e test se voglio solo 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 in cui vengono memorizzati. In Postman tutte le richieste vengono memorizzate da qualche parte in uno spazio di archiviazione locale. Se c'\u00e8 bisogno di condividere le richieste tra pi\u00f9 utenti, \u00e8 necessario utilizzare la sincronizzazione integrata. In realt\u00e0, questo \u00e8 un approccio comune, ma non privo di svantaggi. E per quanto riguarda la sicurezza dei dati? La politica di alcune aziende pu\u00f2 non consentire di memorizzare dati presso terzi. Tuttavia, riteniamo che TestMace possa offrire qualcosa di meglio! E il nome di questo miglioramento \u00e8: \u00abformato di progetto leggibile dall'uomo\u00bb.<\/p>\n

<\/p>\n

Cominciamo col fatto che in TestMace esiste in effetti un'entit\u00e0 chiamata \u201cprogetto\u201d. L'applicazione \u00e8 stata originariamente sviluppata con l'obiettivo di memorizzare progetti nei sistemi di controllo versione: l'albero del progetto si proietta praticamente uno a uno sulla struttura dei file, utilizzando il formato yaml (senza parentesi e virgole superflue), e la rappresentazione file di ogni nodo \u00e8 descritta nel dettaglio nella documentazione con commenti. Ma nella maggior parte dei casi non dovrete guardare l\u00ec \u2014 tutti i nomi dei campi hanno denominazioni logiche. <\/p>\n

<\/p>\n

Cosa offre agli utenti? Questo consente di cambiare il flusso di lavoro del team in modo molto flessibile, utilizzando approcci familiari. Ad esempio, gli sviluppatori possono memorizzare il progetto nello stesso repository del backend. Nei branch, oltre a modificare direttamente la base di codice, lo sviluppatore pu\u00f2 correggere gli scenari di richiesta esistenti e i test. Dopo aver registrato le modifiche nel repository (git, svn, mercurial \u2014 quello che preferite) il CI (la vostra amata, non imposta da nessuno) avvia la nostra utility da console. testmace-cli<\/a><\/noindex>, e il rapporto ottenuto dopo l'esecuzione (ad esempio, in formato junit, anch'esso supportato in testmace-cli) viene inviato al sistema corrispondente. Inoltre, la questione della sicurezza sopra menzionata non rappresenta pi\u00f9 un problema.<\/p>\n

<\/p>\n

Come potete vedere, TestMace non impone il proprio ecosistema e paradigma. Al contrario, 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, cerchiamo di offrire tale possibilit\u00e0. Lavorare con le variabili \u00e8 proprio quella funzionalit\u00e0 in cui, nella maggior parte dei casi, si pu\u00f2 fare a meno della programmazione.<\/p>\n

<\/p>\n

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

<\/p>\n

var jsonData = JSON.parse(responseBody);\npostman.setEnvironmentVariable(\"data\", jsonData.data);<\/code><\/pre>\n
<\/p>\n
Ma a nostro avviso, scrivere uno script per uno scenario cos\u00ec semplice e frequentemente utilizzato appare superfluo. Ecco perch\u00e9 in TestMace c'\u00e8 la possibilit\u00e0 di assegnare a una variabile un pezzo della risposta utilizzando l'interfaccia grafica. Scoprite quanto sia 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 permette non solo di effettuare un'assegnazione, ma anche di eseguire un certo pre-processing. 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
Bene, per questo in TestMace c'\u00e8 script<\/a><\/noindex> un nodo che copre questo scenario. Per riprodurre il caso precedente, ma gi\u00e0 in esecuzione con 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 di nuovo svolto un buon lavoro. E per un caso cos\u00ec semplice come quello descritto sopra, potete semplicemente assegnare l'espressione ${crypto.MD5($response.data)}<\/code> a una variabile creata attraverso 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 vantaggi indiscutibili: flessibilit\u00e0 praticamente illimitata, soluzioni pronte all'uso, e cos\u00ec via.<\/p>\n
<\/p>\n
Tuttavia, la realt\u00e0 \u00e8 spesso tale (non siamo noi, \u00e8 la vita) che il tester non possiede abilit\u00e0 di programmazione, mentre sarebbe desideroso di contribuire al team gi\u00e0 da subito. Per situazioni come queste, seguendo il concetto di no-code, TestMace consente di creare test semplici attraverso un'interfaccia grafica, senza dover scrivere script. Ecco, ad esempio, come appare il processo di creazione di un test che confronta i valori per l'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 in codice<\/a><\/noindex>. Qui troviamo tutte le stesse librerie che si trovano nel nodo script, e chai<\/a><\/noindex> per scrivere test.<\/p>\n
<\/p>\n
Altre differenze<\/h2>\n
<\/p>\n