Test di un lavoratore Asset compute

Il progetto di Asset compute definisce un pattern per creare ed eseguire facilmente test di Asset compute worker.

Anatomia di un test operaio

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 che affermano una condizione da sottoporre a test.

La struttura dei test in un progetto di 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
rendition.<extension>
- Rendering previsto
- Obbligatorio, ad eccezione del test di errore
params.json
- Istruzioni JSON per il rendering singolo
- Facoltativo
validate
- Uno script che ottiene il percorso previsto ed effettivo del file di rendering come argomenti e deve restituire il codice di uscita 0 se il risultato è positivo, o un codice di uscita diverso da zero se la convalida o il confronto non è riuscito.
- Facoltativo, impostazioni predefinite per il comando diff
- Utilizzare uno script shell che racchiude un comando di esecuzione docker per utilizzare diversi strumenti di convalida
mock-<host-name>.json
- Risposte HTTP formattate JSON per schermare le chiamate al servizio esterno.
- Facoltativo, utilizzato solo se il codice del processo di lavoro rende proprie le richieste HTTP.

Scrittura di un caso di test

Questo caso di test afferma l'input parametrizzato (params.json) per il file di input (file.jpg) genera il rendering PNG previsto (rendition.png).

Elimina innanzitutto il caso di test generato automaticamente simple-worker in /test/asset-compute/simple-worker perché non è valido, in quanto il nostro lavoro non copia più semplicemente l'origine nel rendering.
Crea una nuova cartella di test case in /test/asset-compute/worker/success-parameterized per verificare l’esecuzione corretta del processo di lavoro che genera un rendering PNG.
Nella cartella success-parameterized , aggiungi il file di input di prova a2/> per questo test case e denominalo file.jpg.
Nella cartella success-parameterized , aggiungi un nuovo file denominato params.json che definisce i parametri di input del processo di lavoro:
```
{
    "size": "400",
    "contrast": "0.25",
    "brightness": "-0.50"
}
```
Si tratta degli stessi chiave/valori passati nella definizione del profilo Asset compute dello strumento di sviluppo 🔗, meno la chiave worker.
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.
Dalla riga di comando, esegui i test della directory principale del progetto eseguendo aio app test
- Assicurati che Docker Desktop e che le immagini Docker di supporto siano installate e avviate
- Termina qualsiasi istanza dello strumento di sviluppo in esecuzione

Test - Completato

Scrittura di un caso di test di verifica dell'errore

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

Crea una nuova cartella di test case in /test/asset-compute/worker/error-contrast per testare un'esecuzione di errore del processo di lavoro a causa di un valore di parametro contrast non valido.
Nella cartella error-contrast , aggiungi il file di input di prova a2/> per questo test case e denominalo file.jpg. Il contenuto di questo file è irrilevante per questo test, deve solo esistere per superare il controllo "Sorgente danneggiata", per raggiungere i rendition.instructions controlli di validità, che questo test case convalida.
Nella cartella error-contrast , aggiungi un nuovo file denominato params.json che definisce i parametri di input del processo di lavoro con il contenuto:
```
{
    "contrast": "10",
    "errorReason": "rendition_instructions_error"
}
```
- Imposta i parametri contrast su 10, un valore non valido, in quanto il contrasto deve essere compreso tra -1 e 1, per generare un valore RenditionInstructionsError.
- Asserisci che l’errore appropriato venga 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 l' errorReason sul motivo dell'errore o rendition_instructions_error per asserire che viene generato.
Poiché non deve essere generato alcun rendering durante un'esecuzione errata, non è necessario alcun file rendition.<extension>.
Esegui la suite di test dalla radice del progetto eseguendo il comando aio app test
- Assicurati che Docker Desktop e che le immagini Docker di supporto siano installate e avviate
- Termina qualsiasi istanza dello strumento di sviluppo in esecuzione