Eseguire il test di un processo di lavoro Asset compute
Il progetto di Asset compute definisce un pattern che consente di creare ed eseguire facilmente prove sui lavoratori Asset compute.
Anatomia di un test di lavoro
I test dei lavoratori 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 di origine da testare (l’estensione può essere qualsiasi cosa tranne
.link
) - Obbligatorio
- File di origine da testare (l’estensione può essere qualsiasi cosa tranne
-
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, il valore predefinito è
diff
comando - Utilizza uno script della shell che racchiude un comando di esecuzione docker per l’utilizzo di diversi strumenti di convalida
-
mock-<host-name>.json
- Risposte HTTP in formato JSON per beffa delle chiamate di servizio esterne.
- Facoltativo, utilizzato solo se il codice del lavoratore effettua proprie richieste HTTP
Scrittura di un test case
Questo test case afferma l'input con parametri (params.json
) per il file di input (file.jpg
) genera la rappresentazione PNG prevista (rendition.png
).
-
Elimina innanzitutto il file generato automaticamente
simple-worker
test case su/test/asset-compute/simple-worker
poiché questo non è valido, poiché il nostro lavoratore non copia più semplicemente l’origine nella rappresentazione. -
Crea una nuova cartella di test case in
/test/asset-compute/worker/success-parameterized
per verificare la corretta esecuzione del processo di lavoro che genera una rappresentazione PNG. -
In
success-parameterized
, aggiungi il test file di input per questo caso di test e denominalofile.jpg
. -
In
success-parameterized
cartella, aggiungi un nuovo file denominatoparams.json
che definisce i parametri di input del lavoratore:code language-json { "size": "400", "contrast": "0.25", "brightness": "-0.50" }
Questi sono gli stessi valori chiave trasmessi nel Definizione del profilo di Asset compute dello strumento di sviluppo, meno
worker
chiave. -
Aggiungi il previsto file di rappresentazione a questo caso di test e denominalo
rendition.png
. Questo file rappresenta l'output previsto del processo di lavoro per l'input specificatofile.jpg
. -
Dalla riga di comando, esegui i test della directory principale del progetto eseguendo
aio app test
- Assicurare Docker Desktop e le immagini Docker di supporto vengono installate e avviate
- Termina tutte le istanze dello strumento di sviluppo in esecuzione
Scrittura di un test case di controllo degli errori
Questo test case verifica che il lavoratore generi l'errore appropriato quando contrast
parametro impostato su un valore non valido.
-
Crea una nuova cartella di test case in
/test/asset-compute/worker/error-contrast
per verificare un'esecuzione errata del lavoratore a causa di un errorecontrast
valore del parametro. -
In
error-contrast
, aggiungi il test file di input per questo caso di test e denominalofile.jpg
. Il contenuto di questo file non è rilevante per questo test, deve solo esistere per superare il controllo "Origine danneggiata", al fine di raggiungererendition.instructions
controlli di validità, che il test case convalida. -
In
error-contrast
cartella, aggiungi un nuovo file denominatoparams.json
che definisce i parametri di input del lavoratore con il contenuto:code language-json { "contrast": "10", "errorReason": "rendition_instructions_error" }
- Imposta
contrast
parametri per10
, un valore non valido, poiché il contrasto deve essere compreso tra -1 e 1, per generare unRenditionInstructionsError
. - Asserire che l’errore appropriato viene generato nei test impostando
errorReason
chiave del "motivo" associato all’errore previsto. Questo parametro di contrasto non valido genera il errore personalizzato,RenditionInstructionsError
, pertanto imposta ilerrorReason
al motivo di questo errore, oppurerendition_instructions_error
per affermare che è stato lanciato.
- Imposta
-
Poiché non deve essere generata alcuna rappresentazione durante un’esecuzione errata, no
rendition.<extension>
è necessario. -
Esegui la suite di test dalla directory principale del progetto eseguendo il comando
aio app test
- Assicurare Docker Desktop e le immagini Docker di supporto vengono installate e avviate
- Termina tutte le istanze dello strumento di sviluppo in esecuzione
Casi di test su Github
I test case finali sono disponibili su Github all’indirizzo: