DokumentationAEMSjälvstudiekurser om AEMSjälvstudiekurser om AEM as a Cloud Service

Testa en Asset Compute-arbetare

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

Skapat för:

  • Mellanliggande
  • Erfaren
  • Utvecklare

Asset Compute-projektet definierar ett mönster för att enkelt skapa och köra test av Asset Compute-arbetare.

Anatomi i ett arbetartest

Asset Compute arbetares tester delas upp i testsviter och inom varje testsvit finns ett eller flera testfall där ett villkor ska testas.

Teststrukturen i ett Asset Compute-projekt är följande:

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

Varje testskiftning kan ha följande filer:

  • file.<extension>

    • Source-fil att testa (tillägg kan vara vad som helst förutom .link)
    • Obligatoriskt

  • rendition.<extension>

    • Förväntad återgivning
    • Obligatoriskt, utom för feltestning

  • params.json

    • JSON-instruktioner för en rendering
    • Valfritt

  • validate

    • Ett skript som får förväntade och faktiska sökvägar för återgivningsfilen som argument och måste returnera avslutningskod 0 om resultatet är OK, eller en avslutningskod som inte är noll om valideringen eller jämförelsen misslyckas.
    • Valfritt, används som standard kommandot diff
    • Använd ett skalskript som omsluter ett dockningskommando för olika valideringsverktyg

  • mock-<host-name>.json

Skriva ett testfall

Det här testfallet kontrollerar parametriserade indata (params.json) för indatafilen (file.jpg) och genererar den förväntade PNG-återgivningen (rendition.png).

  1. Ta först bort det automatiskt genererade simple-worker-testfallet vid /test/asset-compute/simple-worker eftersom det är ogiltigt, eftersom vår arbetare inte längre bara kopierar källan till återgivningen.

  2. Skapa en ny testfallsmapp på /test/asset-compute/worker/success-parameterized för att testa en lyckad körning av arbetaren som genererar en PNG-återgivning.

  3. Lägg till indatafilen för testet i mappen success-parameterized och ge det namnet file.jpg.

  4. I mappen success-parameterized lägger du till en ny fil med namnet params.json som definierar arbetarens indataparametrar:

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

    Det här är samma nyckel/värden som skickas till Asset Compute-profildefinitionen för utvecklingsverktyget, minus worker.

  5. Lägg till den förväntade återgivningsfilen i det här testfallet och ge den namnet rendition.png. Den här filen representerar förväntade utdata för arbetaren för den angivna inmatningen file.jpg.

  6. Kör testerna av projektroten från kommandoraden genom att köra aio app test

    • Kontrollera att Docker Desktop och tillhörande Docker-bilder är installerade och startade
    • Avsluta alla instanser av utvecklingsverktyget som körs

Test - lyckades

Skriva ett fel vid kontroll av testfall

Det här testfallet testar för att säkerställa att arbetaren genererar rätt fel när parametern contrast är inställd på ett ogiltigt värde.

  1. Skapa en ny testfallsmapp på /test/asset-compute/worker/error-contrast för att testa en felkörning av arbetaren på grund av ett ogiltigt contrast-parametervärde.

  2. Lägg till indatafilen för testet i mappen error-contrast och ge det namnet file.jpg. Innehållet i den här filen är inte väsentligt för det här testet. Det behöver bara finnas för att komma förbi kontrollen "Skadad källa", för att kunna nå de rendition.instructions-valideringskontroller som det här testfallet validerar.

  3. I mappen error-contrast lägger du till en ny fil med namnet params.json som definierar arbetarens indataparametrar med innehållet:

    code language-json 
    {
    "contrast": "10",
    "errorReason": "rendition_instructions_error"
}
    • Ange contrast-parametrar till 10, ett ogiltigt värde eftersom kontrasten måste vara mellan -1 och 1, för att generera RenditionInstructionsError.
    • Kontrollera att rätt fel genereras i tester genom att ange nyckeln errorReason till "reason" som är associerad med det förväntade felet. Den här ogiltiga kontrastparametern genererar det anpassade felet ​, RenditionInstructionsError, och därför anges errorReason till felets orsak, eller rendition_instructions_error för att bekräfta att det genereras.

  4. Eftersom ingen återgivning ska genereras under en körning krävs ingen rendition.<extension>-fil.

  5. Kör testsviten från projektets rot genom att köra kommandot aio app test

    • Kontrollera att Docker Desktop och tillhörande Docker-bilder är installerade och startade
    • Avsluta alla instanser av utvecklingsverktyget som körs

Testa - Felkontrast

Testfall på Github

De sista testfallen finns på Github:

Felsökning

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