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 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 unit-test-framework

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 add-tests

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 test-output

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 mock-external-services

È 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 share-files-across-test-cases

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 test-unexpected-errors

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.

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 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.

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.

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