Testare ed eseguire il debug di un'applicazione personalizzata test-debug-custom-worker

Eseguire unit test per un'applicazione personalizzata test-custom-worker

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

$ aio app test

In questo modo viene eseguito un framework di unit test personalizzato per azioni dell'applicazione di Asset compute nel progetto, come descritto di seguito. È collegato tramite una configurazione in package.json file. È inoltre possibile disporre di unit test JavaScript, ad esempio Jest. aio app test esegue entrambi.

Il aio-cli-plugin-asset-compute il plug-in è incorporato come dipendenza dallo sviluppo nell’app dell’applicazione personalizzata, pertanto non deve essere installato sui sistemi di build/test.

Framework di test delle unità applicative unit-test-framework

Il framework di test di unità applicativa di Asset compute 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 add-tests

Sono previsti test all’interno del test cartella a livello principale della Adobe I/O progetto. I casi di test per ogni applicazione devono essere 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

Dai un'occhiata a esempi di applicazioni personalizzate per alcuni esempi. Di seguito è riportato un riferimento dettagliato.

Output di prova test-output

L’output del test dettagliato, compresi i registri dell’applicazione personalizzata, è disponibile nella sezione build nella directory principale dell'app Adobe Developer App Builder, come illustrato nella aio app test output.

Mascherare i servizi esterni mock-external-services

È possibile simulare chiamate di servizio esterne nelle azioni definendo mock-<HOST_NAME>.json file nei tuoi casi di test, dove HOST_NAME è l'host che desideri simulare. 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 esistono più nomi host da simulare, definire più mock-<mocked-host>.json file. 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 share-files-across-test-cases

Si consiglia di utilizzare i symlink relativi se si condividono file.*, params.json o validate script in più test. Sono supportate 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 test-unexpected-errors

I casi di test di errore non devono contenere un rendition.* e deve definire il errorReason all'interno del params.json file.

Struttura del test case di errore:

<error_test_case>/
    file.jpg
    params.json

File di parametri con motivo errore:

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

Vedi elenco completo e descrizione di Motivi di errore Asset compute.

Eseguire il debug di un'applicazione personalizzata debug-custom-worker

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.

Molti di questi passaggi sono in genere automatizzati da aio con, consulta la sezione Debug dell’applicazione in Documentazione di Adobe Developer App Builder. Per il momento, i passaggi seguenti includono una soluzione alternativa.

Eventuali modifiche al codice vengono caricate in tempo reale e diventano effettive non appena si verifica l’attivazione successiva.