Test dei connettori
Comando test
Il comando test viene utilizzato per testare gli elementi del connettore. Gli elementi sono costituiti da alcune opzioni comuni e alcune opzioni specifiche. Il comando test accetta il tipo dell'elemento come sottocomando e include i comandi seguenti:
Comandi | Descrizione |
|---|---|
flow test action <name> | Testa l'azione <nome>. |
flow test connection <name> | Testa la connessione <nome>. |
flow test lookup <name> <method> | Testa la funzione di ricerca <metodo> nella ricerca <nome>. |
flow test oauth <name> | Testa la configurazione OAuth <nome>. |
flow test trigger <name> <method> | Testa il trigger <nome>. |
Il comando test comprende le opzioni seguenti:
Opzioni | Descrizione | Tipo di dati |
|---|---|---|
--version | Visualizza il numero di versione. | [booleano] |
--help | Visualizza la guida. | [booleano] |
--timeout | Timeout dell'operazione. L'opzione --timeout specifica un timeout in millisecondi (il valore di default è 30000 ms). Questa opzione assicura che il codice finisca entro il tempo specificato e acquisisce gli errori, ad esempio la mancata chiamata dei callback. | [default: 30000] |
--logLevel,-1 | Imposta il livello di registrazione. | [default: "info"] |
ThingWorx Flow CLI consente di testare singoli elementi prima di distribuire il connettore sul server. Ciò consente di verificare se gli elementi funzionano correttamente prima della distribuzione del connettore.
I test case vengono scritti utilizzando il framework mocha-chai. Mocha viene utilizzato per definire la suite di test e chai viene utilizzato come libreria di condizioni. Tutti i test case vengono definiti nella cartella testData sotto una cartella di test di un elemento specifico.
Il comando test consente di testare gli elementi nell'interfaccia della riga di comando di ThingWorx Flow.
Per testare un elemento, eseguire i comandi seguenti dal prompt dei comandi:
1. cd <user project root directory>
2. flow test <artifactType> <name>
Configurazione per testare i protocolli OAuth e i trigger
I comandi flow test oauth e flow test trigger avviano internamente un server Web. Il server Web accetta solo richieste https. Affinché il server possa rispondere alle richieste di configurazione, è necessaria la presenza di certificati. Se mancano i certificati, si verifica il seguente errore:
[2018-09-19T10:13:11.876] [ERROR] trigger - Validation of trigger failed : ENOENT: no such file or directory, open 'C:\[2018-09-19T10:13:11.876] [ERROR] trigger - Validation of trigger failed : ENOENT: no such file or directory, open 'C:\<user-home-dir\.flow\key.pem>
Per creare un certificato autofirmato, attenersi alla procedura riportata di seguito.
1. Scaricare e installare openssl.
2. Presupponendo che openssl si trovi nel percorso, eseguire openssl req -nodes -new -x509 -keyout key.pem -out cert.pem
3. Copiare questi file nella directory .flow nella home directory dell'utente.
Per configurare il nome host e la porta, creare un file flow.json nella directory .flow all'interno della home directory dell'utente. Segue un file di esempio:
{
"passphrase": "xyz",
"hostname" : "flow.local.rnd.ptc.com",
"port" : 443
}
"passphrase": "xyz",
"hostname" : "flow.local.rnd.ptc.com",
"port" : 443
}
Tutte le proprietà sono facoltative.
• Passphrase - Utilizzato con la chiave privata che richiede una passphrase.
• Hostname - Utilizzato per creare l'elemento redirect_uri per OAuth e per creare gli URL dei trigger. Molti servizi potrebbero non consentire l'uso di localhost come nome host valido in redirect_uri. Alcune applicazioni richiedono specificatamente un URL non localhost come gli URL di registrazione webhook. È anche possibile provare ad associare l'URL del sistema di sviluppo in uso con il sistema di produzione per finalità di test. Ad esempio, se l'elemento redirect_uri registrato in Google è https://flow.local.rnd.ptc.com/Thingworx/Oauths/oauth/return, il nome host nel file flow.json dovrebbe essere flow.local.rnd.ptc.com. L'host dovrebbe inoltre essere aggiunto nel percorso <%WINDIR%>\system32\drivers\etc\hosts.
 | Per modificare il file, eseguire l'editor come amministratore. |
Test di una configurazione OAuth
Il test della configurazione OAuth viene eseguito attraverso un browser poiché ogni provider OAuth presenta un modulo diverso in cui accettare le credenziali dell'utente. La riga di comando esegue internamente un server Web espresso per elaborare le risposte che vengono inviate dall'IdP ad autenticazione avvenuta o non riuscita.
Per testare una configurazione OAuth, attenersi alla procedura descritta di seguito.
1. Dalla directory del progetto, utilizzare il comando seguente:
flow test oauth <oauth name>
Dopo avere effettuato l'accesso, viene visualizzata la finestra del browser per la convalida OAuth. Per ulteriori informazioni, fare riferimento all'esempio nell'esercitazione.
2. Selezionare la configurazione da testare, quindi fare clic su Validate OAuth configuration o fare clic su Exit.
Test di una connessione
Il comando test connection chiama il metodo validate e successivamente il metodo connect, testa l'input rispetto allo schema di input e testa l'output rispetto allo schema di output.
Per testare una connessione, attenersi alla procedura descritta di seguito.
1. Dalla directory del progetto, utilizzare il comando seguente:
npm install
2. Creare un file di dati di test nel package e completarne i dati con le informazioni del provider di servizi.
Il file contiene i dati di esempio per il test connectionTestData in <DirProgetto>\test\testdata come illustrato nel seguente blocco di codice:
module.exports = {
sampleInput : {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
},
sampleOutput : {
handle: {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
} }
}
sampleInput : {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
},
sampleOutput : {
handle: {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
} }
}
3. Eseguire il comando test utilizzando le opzioni seguenti:
Opzioni | Descrizione | Tipo di dati |
|---|---|---|
--version | Visualizza il numero di versione. | [booleano] |
--help | Visualizza la guida. | [booleano] |
--timeout | Timeout dell'operazione. L'opzione --timeout specifica un timeout in millisecondi (il valore di default è 30000 ms). Questa opzione assicura che il codice finisca entro il tempo specificato e acquisisce gli errori, ad esempio la mancata chiamata dei callback. | [default: 30000] |
--logLevel,-1 | Imposta il livello di registrazione. | [default: "info"] |
--artifactVersion,-v | Versione dell'elemento da testare. | ND |
--projectDir,-d | Directory padre del progetto. | ND |
--input,-i | Nome della variabile di input. | ND |
--output,-o | Nome della variabile di output prevista. | ND |
--testDataFile,-f | Percorso del file testData. | ND |
--save,-s | Salva nell'archivio delle credenziali di un utente. | ND |
--noSchemaValidation,-n | Disattiva la convalida dello schema. | [default: false] |
L'esecuzione del test produce output se entrambi i metodi connect e validate hanno esito positivo. Il comando controlla anche che l'input corrisponda allo schema di input e che l'output corrisponda all'output previsto.
L'opzione --save memorizza l'output del comando connect nel file creds.json nella cartella .flow della home directory dell'utente. L'output dell'esecuzione di questo comando è la chiave rispetto a cui la connessione viene memorizzata nel file. Utilizzare questa chiave in un secondo momento per passare le informazioni di autenticazione memorizzate a un altro comando test.
Test delle ricerche
Le ricerche presentano una struttura diversa rispetto ad altri elementi e le versioni vengono loro attribuite in modo diverso che ad altri elementi. Il nome stesso serve come versione. Se è richiesta una funzionalità più recente, viene creata una nuova ricerca con un nuovo nome nel file JavasScript delle ricerche. Eseguire il comando test per le ricerche utilizzando il comando seguente:
Di seguito sono elencate le opzioni disponibili.
Opzioni | Descrizione | Tipo di dati |
|---|---|---|
--version | Visualizza il numero di versione. | [booleano] |
--help | Visualizza la guida. | [booleano] |
--timeout | Timeout dell'operazione. L'opzione --timeout specifica un timeout in millisecondi (il valore di default è 30000 ms). Questa opzione assicura che il codice finisca entro il tempo specificato e acquisisce gli errori, ad esempio la mancata chiamata dei callback. | [default: 30000] |
--logLevel,-1 | Imposta il livello di registrazione. | [default: "info"] |
--projectDir,-d | Directory padre del progetto. | ND |
--connection,-c | UID della connessione da inserire. | ND |
--access_token,-a | Nome della variabile di output prevista. | ND |
--input,-i | Percorso del file testData. | ND |
--output,-o | Nome della variabile di output prevista. | ND |
--testDataFile,-f | Percorso del file testData. | ND |
--searchById | ID da utilizzare per la ricerca. | ND |
--searchByValue | Valore da utilizzare per la ricerca. | ND |
--filter | Filtro da utilizzare per cercare gli elementi. | ND |
flow test lookup <name> <method>
Le ricerche presentano due opzioni di ricerca, searchById e searchByValue, e le seguenti tre opzioni relative all'impaginazione.
• La ricerca restituisce tutti i dati contemporaneamente: per questa opzione non è necessaria alcuna azione.
• API di impaginazione supportata dall'applicazione - Il codice di ricerca chiama l'API getNextPage e le passa argomenti che possono aiutare il servizio a restituire i dati dalla pagina successiva. Queste informazioni vengono passate alla ricerca quando l'utente fa clic su Carica altro nell'elenco a discesa dei valori del campo di ricerca.
• Impaginazione non supportata - L'applicazione esegue interrogazioni sui dati e il servizio di ricerca tronca i dati in modo da visualizzare solo i record della pagina corrente e di tutte le pagine precedenti.
Test di azioni
Il test delle azioni è simile al test delle ricerche. Le ricerche non vengono testate nell'ambito del test dell'azione. L'input dovrebbe già contenere i risultati che vengono altrimenti forniti dalle ricerche.
Per testare un'azione, attenersi alla procedura descritta di seguito.
1. Scrivere codice JSON di input e di output di esempio in un file di dati di test. Per esempi di input e di output, fare riferimento all'Esercitazione B.
2. Dalla directory del progetto, eseguire il comando test utilizzando le opzioni seguenti:
Opzioni | Descrizione | Tipo di dati |
|---|---|---|
--version | Visualizza il numero di versione. | [booleano] |
--help | Visualizza la guida. | [booleano] |
--timeout | Timeout dell'operazione. L'opzione --timeout specifica un timeout in millisecondi (il valore di default è 30000 ms). Questa opzione assicura che il codice finisca entro il tempo specificato e acquisisce gli errori, ad esempio la mancata chiamata dei callback. | [default: 30000] |
--logLevel,-1 | Imposta il livello di registrazione. | [default: "info"] |
--artifactVersion,-v | Versione dell'elemento da testare. | [default: "v1"] |
--connection,-c | UID della connessione da inserire. | ND |
--access_token,-a | Nome della variabile di output prevista. | ND |
--projectDir,-d | Directory padre del progetto. | [default: "."] |
--input,-i | Percorso del file testData. | ND |
--output,-o | Nome della variabile di output prevista. | ND |
--testDataFile,-f | Percorso del file testData. | ND |
--noSchemaValidation,-n | Disattiva la convalida dello schema. | [default: false] |
Test di trigger
Il test di un trigger è leggermente diverso da quello di un'azione, una connessione e una ricerca. È possibile eseguire il comando test utilizzando le opzioni seguenti:
La tabella riportata di seguito descrive le varie opzioni disponibili per testare i trigger.
Opzioni | Descrizione | Tipo di dati |
|---|---|---|
--version | Visualizza il numero di versione. | [booleano] |
--help | Visualizza la guida. | [booleano] |
--timeout | Timeout dell'operazione. L'opzione --timeout specifica un timeout in millisecondi (il valore di default è 30000 ms). Questa opzione assicura che il codice finisca entro il tempo specificato e acquisisce gli errori, ad esempio la mancata chiamata dei callback. | [default: 30000] |
--logLevel,-1 | Imposta il livello di registrazione. | [default: "info"] |
--artifactVersion,-v | Versione dell'elemento da testare. | [default: "v1"] |
--connection,-c | UID della connessione da inserire. | ND |
--access_token,-a | Nome della variabile di output prevista. | ND |
--projectDir,-d | Directory padre del progetto. | [default: "."] |
--input,-i | Nome della variabile di input. | ND |
--output,-o | Nome della variabile di output prevista. | ND |
--testDataFile,-f | Percorso del file testData. | ND |
--noSchemaValidation,-n | Disattiva la convalida dello schema. | [default: false] |
--polling,-p | Indica che si tratta di un trigger polling. | ND |
--event,-e | Evento da testare. | ND |
--mockData,-m | Nome della variabile che contiene i mockdata di un evento. | ND |
--interval,-t | Intervallo in secondi da attendere prima di attivare. | [default: 15] |
--stopAfter,-s | Numero massimo di chiamate al trigger. | [default: 1] |
È necessario specificare il metodo che si desidera testare. Per i trigger polling, i metodi sono execute e activate.
Per esempi sul test di vari elementi, fare riferimento all'Esercitazione B.