DocumentazioneAEMTutorial su AEMTutorial su AEM as a Cloud Service

Testare un processo di lavoro Asset Compute

Last update: Tue Oct 14 2025 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Si applica a:
  • Experience Manager as a Cloud Service

Creato per:

  • Intermedio
  • Esperto
  • Sviluppatore

Il progetto Asset Compute definisce un modello per la creazione e l'esecuzione di test dei processi di lavoro Asset Compute.

Anatomia di un test di lavoro

I test dei processi di lavoro di Asset Compute vengono suddivisi in suite di test e, all’interno di ogni suite di test, uno o più casi di test affermano una condizione da testare.

La struttura dei test in un progetto Asset Compute è la seguente:

/actions/<worker-name>/index.js
...
/test/
  asset-compute/
    <worker-name>/           <--- Test suite for the worker, must match the yaml key for this worker in manifest.yml
        <test-case-1>/       <--- Specific test case
            file.jpg         <--- Input file (ie. `source.path` or `source.url`)
            params.json      <--- Parameters (ie. `rendition.instructions`)
            rendition.png    <--- Expected output file (ie. `rendition.path`)
        <test-case-2>/       <--- Another specific test case for this worker
            ...

Ogni cast di test può avere i seguenti file:

  • file.<extension>

    • File Source da testare (l'estensione può essere qualsiasi cosa tranne .link)
    • Obbligatorio

  • rendition.<extension>

    • Rendering previsto
    • Obbligatorio, ad eccezione della verifica degli errori

  • params.json

    • Istruzioni JSON per la rappresentazione singola
    • Facoltativo

  • validate

    • Uno script che ottiene come argomenti i percorsi previsti ed effettivi del file di rendering e deve restituire il codice di uscita 0 se il risultato è ok, o un codice di uscita diverso da zero se la convalida o il confronto non è riuscito.
    • Facoltativo, viene impostato automaticamente sul comando diff
    • Utilizza uno script della shell che racchiude un comando di esecuzione docker per l’utilizzo di diversi strumenti di convalida

  • mock-<host-name>.json

Scrittura di un test case

Questo caso di test afferma l'input con parametri (params.json) per il file di input (file.jpg) genera la rappresentazione PNG prevista (rendition.png).

  1. Eliminare prima il caso dei test di simple-worker generati automaticamente in /test/asset-compute/simple-worker perché non è valido, in quanto il processo di lavoro non copia più semplicemente l'origine nella rappresentazione.

  2. Creare una nuova cartella dei test case in /test/asset-compute/worker/success-parameterized per verificare la corretta esecuzione del processo di lavoro che genera una rappresentazione PNG.

  3. Nella cartella success-parameterized aggiungere il file di input di test per questo test case e denominarlo file.jpg.

  4. Nella cartella success-parameterized, aggiungere un nuovo file denominato params.json che definisce i parametri di input del processo di lavoro:

    code language-json 
    {
    "size": "400",
    "contrast": "0.25",
    "brightness": "-0.50"
}

    Questi sono gli stessi valori di chiave passati nella definizione del profilo Asset Compute🔗 dello strumento di sviluppo , meno la chiave worker.

  5. Aggiungi il file di rendering previsto a questo test case e denominalo rendition.png. Questo file rappresenta l'output previsto del processo di lavoro per l'input specificato file.jpg.

  6. Dalla riga di comando, eseguire i test della directory principale del progetto eseguendo aio app test

    • Verificare che Docker Desktop e le immagini Docker di supporto siano installati e avviati
    • Termina tutte le istanze dello strumento di sviluppo in esecuzione

Test - Completato

Scrittura di un test case di controllo degli errori

Questo test case verifica che il processo di lavoro generi l'errore appropriato quando il parametro contrast è impostato su un valore non valido.

  1. Creare una nuova cartella dei test case in /test/asset-compute/worker/error-contrast per testare un'esecuzione errata del processo di lavoro a causa di un valore del parametro contrast non valido.

  2. Nella cartella error-contrast aggiungere il file di input di test per questo test case e denominarlo file.jpg. Il contenuto di questo file non è rilevante per il test. È sufficiente che esista per superare il controllo "Origine danneggiata" per raggiungere i rendition.instructions controlli di validità convalidati dal test case.

  3. Nella cartella error-contrast, aggiungere un nuovo file denominato params.json che definisce i parametri di input del processo di lavoro con il contenuto:

    code language-json 
    {
    "contrast": "10",
    "errorReason": "rendition_instructions_error"
}
    • Impostare i parametri contrast su 10. Valore non valido. Il contrasto deve essere compreso tra -1 e 1 per generare un RenditionInstructionsError.
    • Asserire che l'errore appropriato viene generato nei test impostando la chiave errorReason sul "motivo" associato all'errore previsto. Questo parametro di contrasto non valido genera l'errore personalizzato, RenditionInstructionsError, quindi imposta errorReason sul motivo dell'errore oppure rendition_instructions_error per verificare che sia stato generato.

  4. Poiché durante un'esecuzione errata non deve essere generata alcuna rappresentazione, non è necessario alcun file rendition.<extension>.

  5. Eseguire il gruppo di test dalla radice del progetto eseguendo il comando aio app test

    • Verificare che Docker Desktop e le immagini Docker di supporto siano installati e avviati
    • Termina tutte le istanze dello strumento di sviluppo in esecuzione

Test - Contrasto errore

Casi di test su Github

I test case finali sono disponibili su Github all’indirizzo:

Risoluzione dei problemi

recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69