Test ed esecuzione del debug di un'applicazione personalizzata

Esegui unit test per un'applicazione personalizzata

Installa Docker Desktop sul computer. Per testare un processo di lavoro personalizzato, eseguire il comando seguente nella directory principale dell'applicazione:

$ aio app test

Viene eseguito un framework di test di unità personalizzata per Asset compute le azioni dell’applicazione nel progetto come descritto di seguito. Viene collegato tramite una configurazione nel file package.json . È anche possibile avere unit test JavaScript come Jest. aio app test esegue entrambe.

Il plug-in aio-cli-plugin-asset-compute è incorporato come dipendenza di sviluppo nell'app dell'applicazione personalizzata in modo che non sia necessario installarlo nei sistemi di build/test.

Struttura del test dell'unità applicativa

Il framework di test dell'unità applicativa di Asset compute consente di testare le applicazioni senza scrivere alcun codice. Si basa sul principio di origine del file di rendering delle applicazioni. È necessario impostare una determinata struttura di file e cartelle per definire i casi di test con i file di origine dei test, i parametri facoltativi, le rappresentazioni previste e gli script di convalida personalizzati. Per impostazione predefinita, le rappresentazioni vengono confrontate per l’uguaglianza dei byte. Inoltre, i servizi HTTP esterni possono essere facilmente mascherati utilizzando semplici file JSON.

Aggiungi test

Sono previsti test all'interno della cartella test al livello principale del progetto Adobe I/O. I casi di prova per ciascuna 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

Per alcuni esempi, consulta l’ esempio applicazioni personalizzate . Di seguito è riportato un riferimento dettagliato.

Uscita del test

L’output dettagliato del test, compresi i registri dell’applicazione personalizzata, è disponibile nella cartella build nella directory principale dell’app Firefly, come illustrato nell’ aio app test output.

Bloccare i servizi esterni

È possibile simulare le chiamate al servizio esterno nelle azioni definendo i file mock-<HOST_NAME>.json nei casi di test, dove HOST_NAME è l'host di cui si desidera tenere traccia. Un esempio di caso d'uso è un'applicazione che effettua una chiamata separata a S3. La nuova struttura del 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, definisci più file mock-<mocked-host>.json. Di seguito è riportato un esempio di file di simulazione 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 di tag per il servizio Wikimedia con cui interagisce.

Condividere file tra test case

Si consiglia di utilizzare i collegamenti simbolici relativi se si condividono script file.*, params.json o validate 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 stanno combinando e confrontando alcuni file condivisi e i 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 di errore non devono contenere un file rendition.* previsto e devono definire il errorReason previsto all'interno del file params.json.

Struttura del caso di test di errore:

<error_test_case>/
    file.jpg
    params.json

File di parametro con motivo di errore:

{
    "errorReason": "SourceUnsupported",
    // ... other params
}

Vedi l'elenco completo e la descrizione di Asset compute di motivi di errore.

Debug di un'applicazione personalizzata

I passaggi seguenti mostrano come eseguire il debug dell'applicazione personalizzata utilizzando Visual Studio Code. Consente di visualizzare log in tempo reale, punti di interruzione e codice dettagliato, nonché di ricaricare in tempo reale le modifiche al codice locale a ogni attivazione.

Molti di questi passaggi sono generalmente automatizzati da aio out of the box, vedi la sezione Debug dell'applicazione nella documentazione Firefly. Per il momento, i passaggi seguenti includono una soluzione alternativa.

1. Installa l'ultimo wskdebug da GitHub e l'facoltativo ngrok.

   npm install -g @openwhisk/wskdebug
   npm install -g ngrok --unsafe-perm=true
   

2. Aggiungi al file JSON delle impostazioni utente. Continua a utilizzare il vecchio debugger del codice VS, il nuovo ha alcuni problemi con wskdebug: "debug.javascript.usePreview": false.

3. Chiudi tutte le istanze delle app aperte tramite aio app run.

4. Distribuisci il codice più recente utilizzando aio app deploy.

5. Esegui solo lo strumento Devtool di Asset compute utilizzando aio asset-compute devtool. Tenetela aperta.

6. In Editor di codice VS, aggiungi la seguente configurazione di debug al tuo 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 il ACTION NAME dall'output di aio app deploy.

7. Seleziona wskdebug worker dalla configurazione di esecuzione/debug e premi l'icona di riproduzione. Attendi che inizi finché non viene visualizzato Pronto per le attivazioni nella finestra Console di debug.

8. Fare clic su esegui nel Devtool. Puoi vedere le azioni in esecuzione nell’editor di codice VS e i registri iniziano a essere visualizzati.

9. Imposta un punto di interruzione nel codice, esegui di nuovo e dovrebbe colpire.

Tutte le modifiche al codice vengono caricate in tempo reale e hanno effetto non appena si verifica l’attivazione successiva.