Ciao a tutti, qui è TestMace! Forse molti di voi ci conoscono da noi le precedenti articoli. Per chi si è appena unito: stiamo sviluppando un IDE per lavorare con l'API di TestMace. La domanda più comune quando si confronta TestMace con prodotti concorrenti è: «Cosa vi distingue da Postman?». Abbiamo deciso che era ora di fornire una risposta dettagliata a questa domanda. Di seguito abbiamo elencato i nostri vantaggi rispetto a Postman.

Divisione in nodi

Se lavori con Postman, sai che l'interfaccia di richiesta contiene tutte le funzionalità necessarie. Qui ci sono script, test e, naturalmente, le richieste stesse. Questo semplifica il lavoro per i principianti, ma in scenari più complessi questo approccio non è flessibile. Cosa succede se vuoi creare diverse richieste e aggregarle? Cosa succede se vuoi eseguire uno script senza richiesta o più script logicamente separati uno dopo l'altro? In fin dei conti, sarebbe bello separare i test dagli script utilitari. Inoltre, l'approccio di «aggiungere tutte le funzionalità in un unico nodo» non è scalabile — l'interfaccia diventa rapidamente sovraccarica.

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

Formato leggibile dall'uomo del progetto

Tra TestMace e Postman c'è una differenza concettuale nel modo in cui vengono memorizzati. In Postman tutte le richieste vengono memorizzate da qualche parte nello storage locale. Se è necessario condividere le richieste tra più utenti, è necessario utilizzare la sincronizzazione integrata. In realtà, questo è un approccio comune, non privo di svantaggi. E riguardo alla sicurezza dei dati? Infatti, la politica di alcune aziende può non consentire di memorizzare dati presso terzi. Tuttavia, riteniamo che TestMace possa offrire qualcosa di meglio! E il nome di questo miglioramento è «formato leggibile dall'uomo del progetto».

Iniziamo col dire che in TestMace esiste fondamentalmente l'entità "progetto". L'applicazione è 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 è descritta in dettaglio nella documentazione con commenti. Ma nella maggior parte dei casi non sarà necessario dare un'occhiata a questa — tutti i nomi dei campi hanno denominazioni logiche.

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ò correggere gli scenari di richieste esistenti e i test. Dopo aver registrato le modifiche nel repository (git, svn, mercurial — quello che preferisci), CI (il tuo preferito, non imposto da nessuno) avvia la nostra utility da console testmace-cli, e il rapporto generato dopo l'esecuzione (ad esempio, in formato junit, che è anche supportato in testmace-cli) viene inviato al sistema corrispondente. E anche la questione di cui sopra riguardante la sicurezza non è più un problema.

Come puoi vedere, TestMace non impone il suo ecosistema e paradigma. Invece, si integra facilmente nei processi già consolidati.

Variabili dinamiche

TestMace segue il concetto di no-code: se un problema può essere risolto senza l'uso di codice, ci impegniamo a offrire tale opportunità. Lavorare con le variabili è proprio quella funzionalità nella quale la maggior parte delle volte è possibile fare a meno della programmazione.

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é è strano) qualcosa del tipo:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);

Ma secondo noi, scrivere uno script per uno scenario così semplice e frequentemente utilizzato appare eccessivo. Pertanto, in TestMace è possibile assegnare una parte della risposta a una variabile utilizzando l'interfaccia grafica. Guarda quanto è semplice:

E ora, ad ogni richiesta, questa variabile dinamica verrà aggiornata. Ma potreste obiettare, sostenendo che l'approccio di Postman è più flessibile e consente non solo di effettuare un'assegnazione, ma anche di eseguire una certa pre-elaborazione. Ecco come si può modificare l'esempio precedente:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));

Beh, per questo in TestMace c'è script un nodo che copre questo scenario. Per riprodurre il caso precedente, ma già nell'implementazione di TestMace, è necessario creare un nodo script dopo la richiesta e utilizzare il seguente codice come script:

const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));

Come vedete, la composizione dei nodi ha funzionato bene anche qui. E per un caso così semplice, come descritto sopra, potete semplicemente assegnare l'espressione ${crypto.MD5($response.data)} a una variabile creata tramite l'interfaccia grafica!

Creazione di test tramite GUI

Postman consente di creare test scrivendo script (nel caso di Postman, si tratta di JavaScript). Questo approccio ha solo vantaggi: flessibilità praticamente illimitata, presenza di soluzioni pronte, ecc.

Tuttavia, le realtà sono spesso tali (non siamo noi, è la vita) che il tester non ha competenze di programmazione, e si vorrebbe già 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:

Tuttavia, la creazione di test nell'editor grafico non esclude la possibilità di scrivere test nel codice. Qui ci sono tutte le stesse librerie che nel nodo script, e chai per scrivere i test.

La possibilità di eseguire uno scenario già esistente tramite un link (nodo Link)

Spesso si presentano situazioni in cui una certa richiesta o addirittura un intero scenario devono essere eseguiti più volte in diverse parti del progetto. Un esempio di tali richieste può essere una registrazione personalizzata a più fasi, portare l'ambiente allo stato desiderato, ecc. In breve, se parliamo in termini di linguaggi di programmazione, sarebbe utile avere funzioni che possano essere riutilizzate in diverse parti dell'applicazione. In TestMace questa funzione è svolta da link nodo. È molto semplice usarlo:
1) crea una richiesta o uno script
2) crea un nodo di tipo Link
3) nelle impostazioni indica il link allo script creato al primo passo

Nella versione più avanzata, puoi specificare quali variabili dinamiche dallo script passeranno al livello superiore rispetto al link. Sembra complicato? Supponiamo di aver creato una cartella di nome create-post, all'interno della quale viene assegnata una variabile dinamica a questo nodo postId. Ora, nel nodo Link create-post-link puoi specificare esplicitamente che la variabile postId viene assegnata al genitore create-post-link. Questo meccanismo (di nuovo, usando il linguaggio dei programmatori) può essere utilizzato per restituire un risultato da una "funzione". In generale, è fantastico, DRY in pieno e di nuovo non è stata scritta neppure una riga di codice.

Per quanto riguarda Postman, la richiesta di funzionalità per il riutilizzo delle richieste è in sospeso dal 2015, e sembra che ci siano anche alcuni segnali, che su questo problema stanno lavorando. Nella sua forma attuale, Postman ha sicuramente la possibilità di cambiare il flusso di esecuzione, il che in teoria permette di realizzare un comportamento simile, ma è più un hack sporco che un approccio davvero funzionante.

Altre differenze

• Maggiore controllo sulla visibilità delle variabili. Il minor scope in cui è possibile definire una variabile in Postman è la collezione. TestMace consente di definire variabili per qualsiasi richiesta o cartella. In Postman, la condivisione della collezione consente di esportare solo collezioni, mentre in TestMace la condivisione funziona per qualsiasi nodo
• TestMace supporta header ereditati, che per impostazione predefinita possono essere inseriti nelle richieste figlie. Per quanto riguarda Postman, c'è compito, ed è anche chiusa, ma come soluzione si propone… di utilizzare script. In TestMace tutto ciò è configurato tramite GUI e c'è la possibilità di disattivare opzionalmente gli header ereditati nei discendenti specifici
• Annulla/Rifai. Funziona non solo durante la modifica dei nodi, ma anche durante lo spostamento, la cancellazione, la rinomina e altre operazioni che modificano la struttura del progetto
• I file allegati alle richieste diventano parte del progetto e vengono archiviati con esso, sincronizzandosi perfettamente, a differenza di Postman. (Sì, non è più necessario selezionare manualmente i file ogni volta all'avvio e passarli ai colleghi in archivi)

Funzioni che sono già in arrivo

Non siamo riusciti a resistere alla tentazione di sollevare il velo di mistero sui prossimi rilasci, specialmente considerando quanto sia allettante la funzionalità e che sia già in fase di rifinitura pre-rilascio. Quindi, diamo il benvenuto.

Funzioni

Come è noto, per generare valori in Postman vengono utilizzate le cosiddette variabili dinamiche. L'elenco è impressionante e la stragrande maggioranza delle funzioni serve a generare valori fittizi. Ad esempio, per generare un'email casuale è necessario scrivere:

{{$randomEmail}}

Tuttavia, poiché si tratta di variabili (anche se dinamiche), non possono essere usate come funzioni: non sono parametrizzabili, quindi non è possibile ottenere l'hash da una stringa.

In TestMace intendiamo aggiungere funzioni "oneste". All'interno di ${} sarà possibile non solo fare riferimento a una variabile, ma anche chiamare una funzione. Cioè, se è necessario generare la famigerata email fittizia, scriveremo semplicemente

${faker.internet.email()}

Oltre al fatto che si tratta di una funzione, si può notare che è possibile chiamare un metodo di un oggetto. E invece di un lungo elenco di variabili dinamiche, abbiamo un insieme di oggetti logicamente raggruppati.

E se vogliamo calcolare l'hash di una stringa? Facile!

${crypto.MD5($dynamicVar.data)}

Si può notare che come parametri possono persino essere passate variabili! In questo punto, il lettore curioso potrebbe sospettare qualcosa di strano…

Uso di JavaScript nelle espressioni

… E a ragione! Quando sono stati formulati i requisiti per le funzioni, ci siamo resi conto che nelle espressioni era necessario permettere di scrivere un javascript valido. Pertanto, ora sei libero di scrivere espressioni del tipo:

${1 + '' + crypto.MD5('asdf')}

E tutto questo senza script direttamente nei campi di input!

Per quanto riguarda Postman, qui si possono solo utilizzare variabili e, nel tentativo di scrivere anche una minima espressione, il validatore dà errore e si rifiuta di calcolarla.

Completamento automatico avanzato

Attualmente, TestMace dispone di un completamento automatico standard che appare come segue:

Qui, oltre alla stringa di completamento automatico, viene indicato a cosa appartiene questa stringa. Questo meccanismo funziona solo nelle espressioni racchiuse tra parentesi ${}.

Come si può notare, sono stati aggiunti dei marcatori visivi che indicano il tipo di variabile (ad esempio, stringa, numero, array, ecc.). È possibile anche cambiare le modalità di completamento automatico (ad esempio, si può scegliere il completamento automatico con variabili o intestazioni). Ma anche questo non è il punto principale!

Innanzitutto, il completamento automatico funziona anche nelle espressioni (dove possibile). Ecco come appare:

In secondo luogo, ora il completamento automatico è disponibile anche negli script. Date un'occhiata a come funziona!

Non ha senso confrontare questa funzionalità con Postman — lì, il completamento automatico è limitato solo a liste statiche di variabili, intestazioni e relativi valori (correggetemi se ho dimenticato qualcosa). Gli script non sono soggetti a completamento automatico 🙁

Conclusione

Ad ottobre è passato un anno dall'inizio dello sviluppo del nostro prodotto. In questo periodo abbiamo fatto molto e in alcuni parametri abbiamo raggiunto i nostri concorrenti. Tuttavia, il nostro obiettivo rimane quello di creare uno strumento veramente utile per lavorare con le API. Abbiamo ancora molto lavoro da fare, ecco un piano approssimativo per lo sviluppo del nostro progetto nel prossimo anno: https://testmace.com/roadmap.

Il vostro feedback ci aiuterà a orientarci meglio in un'abbondanza di funzionalità, mentre il vostro supporto ci dà forza e fiducia nel fatto che stiamo facendo qualcosa di necessario. Oggi è un giorno importante per il nostro progetto — il giorno della pubblicazione di TestMace su ProductHunt. Vi preghiamo di supportare il nostro progetto; è molto importante per noi. Inoltre, sulla nostra pagina PH oggi c'è un'offerta allettante, e questa è limitata

Fonte: habr.com