Een aangepaste toepassing testen en fouten hierin opsporen test-debug-custom-worker

Eenheidstests voor een aangepaste toepassing uitvoeren test-custom-worker

Installeer ​ de Desktop van de Dokker ​ op uw machine. Als u een aangepaste worker wilt testen, voert u de volgende opdracht uit in de hoofdmap van de toepassing:

$ aio app test

Met deze opdracht wordt een testframework voor aangepaste eenheden voor Asset Compute-toepassingsacties in het project uitgevoerd, zoals hieronder wordt beschreven. De component is gekoppeld aan een configuratie in het package.json -bestand. Het is ook mogelijk om JavaScript-eenheidstests zoals Jest te laten uitvoeren. De aio app test voert beide uit.

De {🔗 insteekmodule 0} air-cli-insteekmodule-asset-compute wordt ingebed als ontwikkelingsgebiedsdeel in douanetoepassing zodat het niet op bouwstijl/testsystemen moet worden geïnstalleerd.

Testframework voor toepassingseenheid unit-test-framework

Met het testframework voor Asset Compute-toepassingseenheden kunt u toepassingen testen zonder code te schrijven. Het is afhankelijk van het principe van de bron naar het weergavebestand van toepassingen. Er moet een bepaalde bestands- en mapstructuur worden ingesteld om testcase te definiëren met bronbestanden voor tests, optionele parameters, verwachte uitvoeringen en aangepaste validatiescripts. Standaard worden de uitvoeringen vergeleken voor de gelijkheid van bytes. Bovendien kunnen externe HTTP-services eenvoudig worden gecontroleerd met behulp van eenvoudige JSON-bestanden.

Tests toevoegen add-tests

Tests worden verwacht in de map test op het hoofdniveau van het project. De testgevallen voor elke toepassing moeten zich in het pad test/asset-compute/<worker-name> bevinden, met één map voor elk testgeval:

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

Heb een blik bij ​ de toepassingen van de voorbeelddouane ​ voor sommige voorbeelden. Hieronder vindt u een gedetailleerde referentie.

Uitvoer testen test-output

In de map build aan de basis van de Adobe Developer App Builder-app staan de gedetailleerde testresultaten en logboekbestanden van de aangepaste toepassing. Deze details worden ook weergegeven in de uitvoer van de opdracht aio app test .

Externe diensten koppelen mock-external-services

U kunt externe de dienstvraag binnen uw acties simuleren door mock-<HOST_NAME>.json dossiers voor uw testscenario's te creëren, met HOST_NAME die de specifieke gastheer is u van plan bent te animeren. Een geval van het voorbeeldgebruik is een toepassing die een afzonderlijke vraag aan S3 maakt. De nieuwe teststructuur ziet er als volgt uit:

test/
  asset-compute/
    <worker-name>/
      <testcase3>/
        file.jpg
        params.json
        rendition.png
        mock-<HOST_NAME1>.json
        mock-<HOST_NAME2>.json

Het mock-bestand is een http-reactie met JSON-indeling. Voor meer informatie, zie ​ deze documentatie ​. Als er meerdere hostnamen zijn om te controleren, definieert u meerdere mock-<mocked-host>.json -bestanden. Hieronder ziet u een voorbeeldmodelbestand voor google.com genaamd mock-google.com.json :

[{
    "httpRequest": {
        "path": "/images/hello.txt"
        "method": "GET"
    },
    "httpResponse": {
        "statusCode": 200,
        "body": {
          "message": "hello world!"
        }
    }
}]

Het voorbeeld worker-animal-pictures bevat a ​ mock dossier ​ voor de dienst Wikimedia die het met interactie aangaat.

Bestanden delen over testgevallen share-files-across-test-cases

Adobe raadt u aan relatieve symmetrieën te gebruiken als u scripts file.* , params.json of validate deelt over meerdere tests. Ze worden ondersteund met Git. Geef uw gedeelde bestanden een unieke naam, omdat u mogelijk andere bestanden hebt. In het onderstaande voorbeeld mengen en vergelijken de tests een paar gedeelde bestanden en hun eigen bestanden:

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

Verwachte fouten testen test-unexpected-errors

Fouttestgevallen mogen geen verwacht rendition.* -bestand bevatten en moeten de verwachte errorReason in het params.json -bestand definiëren.

Fout bij testen hoofdletterstructuur:

<error_test_case>/
    file.jpg
    params.json

Parameterbestand met reden van fout:

{
    "errorReason": "SourceUnsupported",
    // ... other params
}

Zie een volledige lijst en een beschrijving van ​ de foutenredenen van Asset Compute ​.

Fouten opsporen in een aangepaste toepassing debug-custom-worker

De volgende stappen tonen hoe u uw douanetoepassing kunt zuiveren gebruikend de Code van Visual Studio. Het staat voor het zien van levende logboeken, raakbreekpunten en stap door code evenals het levende opnieuw laden van lokale codeveranderingen na elke activering toe.

Veel van deze stappen worden automatisch uitgevoerd door de functie aio out-of-the-box. Ga naar de sectie die de Toepassing in de ​ documentatie van Adobe Developer App Builder ​ zuiveren. Tot nu toe bevatten de onderstaande stappen een tijdelijke oplossing.

Eventuele codewijzigingen worden in real-time geladen en worden van kracht zodra de volgende activering plaatsvindt.