Testare ed eseguire il debug di un'applicazione personalizzata
- Argomenti:
- Microservizi Asset Compute
Creato per:
- Sviluppatore
Eseguire unit test per un'applicazione personalizzata
Installa Docker Desktop nel computer. Per testare un processo di lavoro personalizzato, eseguire il comando seguente nella radice dell'applicazione:
$ aio app test
Questo comando esegue un framework di unit test personalizzato per azioni dell'applicazione di Asset compute nel progetto come descritto di seguito. È collegato tramite una configurazione nel file package.json. È inoltre possibile disporre di unit test JavaScript, ad esempio Jest. aio app test esegue entrambi.
Il plug-in aio-cli-plugin-asset-compute è incorporato come una dipendenza di sviluppo nell'app dell'applicazione personalizzata, pertanto non è necessario installarlo nei sistemi di build/test.
Framework di test delle unità applicative
L'Asset compute di framework di unit test dell'applicazione consente di testare le applicazioni senza scrivere codice. Si basa sul principio di origine per il rendering del file delle applicazioni. È necessario configurare una determinata struttura di file e cartelle per definire i casi di test con file di origine di test, parametri facoltativi, rappresentazioni previste e script di convalida personalizzati. Per impostazione predefinita, le rappresentazioni vengono confrontate per l'uguaglianza dei byte. Inoltre, i servizi HTTP esterni possono essere facilmente presi in giro utilizzando semplici file JSON.
Aggiungi test
I test sono previsti all'interno della cartella test al livello principale del progetto. I test case per ogni applicazione devono trovarsi nel percorso test/asset-compute/<worker-name>, con una cartella per ogni test case:
action/
manifest.yml
package.json
...
test/
asset-compute/
<worker-name>/
<testcase1>/
file.jpg
params.json
rendition.png
<testcase2>/
file.jpg
params.json
rendition.gif
validate
<testcase3>/
file.jpg
params.json
rendition.png
mock-adobe.com.json
mock-console.adobe.io.json
Guarda esempio di applicazioni personalizzate per alcuni esempi. Di seguito è riportato un riferimento dettagliato.
Output di prova
La directory build nella directory principale dell'app Adobe Developer App Builder contiene i risultati dettagliati dei test e i registri dell'applicazione personalizzata. Questi dettagli vengono visualizzati anche nell'output del comando aio app test.
Mascherare i servizi esterni
È possibile simulare chiamate di servizio esterne all'interno delle azioni creando mock-<HOST_NAME>.json file per gli scenari di test. HOST_NAME è l'host specifico che si intende imitare. Un esempio di caso d’uso è un’applicazione che effettua una chiamata separata a S3. La nuova struttura di test sarà simile alla seguente:
test/
asset-compute/
<worker-name>/
<testcase3>/
file.jpg
params.json
rendition.png
mock-<HOST_NAME1>.json
mock-<HOST_NAME2>.json
Il file fittizio è una risposta HTTP in formato JSON. Per ulteriori informazioni, consulta questa documentazione. Se ci sono più nomi host da simulare, definire più file mock-<mocked-host>.json. Di seguito è riportato un esempio di file fittizio per google.com denominato mock-google.com.json:
[{
"httpRequest": {
"path": "/images/hello.txt"
"method": "GET"
},
"httpResponse": {
"statusCode": 200,
"body": {
"message": "hello world!"
}
}
}]
L'esempio worker-animal-pictures contiene un file fittizio per il servizio Wikimedia con cui interagisce.
Condivisione di file tra test case
L'Adobe consiglia di utilizzare i symlink relativi se si condividono file.*, params.json o validate script in più test. Sono supportati con Git. Assicurati di assegnare ai file condivisi un nome univoco, in quanto potrebbero essere presenti file diversi. Nell’esempio seguente i test si combinano e corrispondono a pochi file condivisi e ai loro:
tests/
file-one.jpg
params-resize.json
params-crop.json
validate-image-compare
jpg-png-resize/
file.jpg - symlink: ../file-one.jpg
params.json - symlink: ../params-resize.json
rendition.png
validate - symlink: ../validate-image-compare
jpg2-png-crop/
file.jpg
params.json - symlink: ../params-crop.json
rendition.gif
validate - symlink: ../validate-image-compare
jpg-gif-crop/
file.jpg - symlink: ../file-one.jpg
params.json - symlink: ../params-crop.json
rendition.gif
validate
Test degli errori previsti
I casi di test degli errori non devono contenere un file rendition.* previsto e devono definire il file errorReason previsto all'interno del file params.json.
NOTErendition.* previsto e non definisce il errorReason previsto all'interno del file params.json, si presume che si tratti di un errore con qualsiasi errorReason.Struttura del test case di errore:
<error_test_case>/
file.jpg
params.json
File di parametri con motivo errore:
{
"errorReason": "SourceUnsupported",
// ... other params
}
Visualizza un elenco completo e una descrizione di motivi di errore Asset compute.
Eseguire il debug di un'applicazione personalizzata
Nei passaggi seguenti viene illustrato come eseguire il debug dell'applicazione personalizzata utilizzando Visual Studio Code. Consente di visualizzare registri live, punti di interruzione di hit e codice step-through, nonché il ricaricamento in tempo reale delle modifiche al codice locale a ogni attivazione.
aio preconfigurato automatizza molti di questi passaggi. Vai alla sezione Debug dell'applicazione nella documentazione di Adobe Developer App Builder. Per il momento, i passaggi seguenti includono una soluzione alternativa.
-
Installa la versione più recente di wskdebug da GitHub e la ngrok facoltativa.
npm install -g @openwhisk/wskdebug npm install -g ngrok --unsafe-perm=true -
Aggiungi delle impostazioni utente al file JSON. Continua a utilizzare il debugger del codice di Visual Studio precedente. Il nuovo ha alcuni problemi con wskdebug:
"debug.javascript.usePreview": false. -
Chiudere tutte le istanze di app aperte tramite
aio app run. -
Distribuire il codice più recente utilizzando
aio app deploy. -
Eseguire solo lo strumento di sviluppo Asset Compute utilizzando
aio asset-compute devtool. Tienilo aperto. -
Nell'editor di codice di Visual Studio aggiungere la seguente configurazione di debug a
launch.json:{ "type": "node", "request": "launch", "name": "wskdebug worker", "runtimeExecutable": "wskdebug", "args": [ "PROJECT-0.0.1/__secured_worker", // Replace this with your ACTION NAME "${workspaceFolder}/actions/worker/index.js", "-l", "--ngrok" ], "localRoot": "${workspaceFolder}", "remoteRoot": "/code", "outputCapture": "std", "timeout": 30000 }Recupera
ACTION NAMEdall'output diaio app deploy. -
Selezionare
wskdebug workerdalla configurazione di esecuzione/debug e premere l'icona di riproduzione. Attendere che venga avviato finché non viene visualizzato Pronto per le attivazioni nella finestra Console di debug. -
Fare clic su esegui in Devtool. È possibile visualizzare le azioni in esecuzione nell'editor di codice di Visual Studio e i registri iniziano a essere visualizzati.
-
Imposta un punto di interruzione nel codice. Quindi esegui di nuovo e dovrebbe colpire.
Eventuali modifiche al codice vengono caricate in tempo reale e diventano effettive non appena si verifica l’attivazione successiva.
NOTE