UI-tests ui-testing

Het testen UI van de douane is een facultatieve eigenschap die u toelaat om tests UI voor uw toepassingen tot stand te brengen en automatisch in werking te stellen.

Overzicht custom-ui-testing

AEM verstrekt een geïntegreerde reeks van ​ de kwaliteitsgates van Cloud Manager ​ om vlotte updates aan douanetoepassingen te verzekeren. Met name de testpoorten van IT ondersteunen al het maken en automatiseren van aangepaste tests met AEM API's.

De tests UI worden verpakt in een beeld van de Docker om een brede keus in taal en kaders (zoals Cypress, Selenium, Java en Maven, en JavaScript) toe te staan. Ook, kan een UI testproject gemakkelijk worden geproduceerd door ​ het Archetype van het Project van AEM ​ te gebruiken.

Adobe moedigt het gebruik van Cypress aan, aangezien het in real time herladen en automatisch wachten aanbiedt, die helpt tijd te besparen en productiviteit tijdens het testen verbetert. Cypress biedt ook een eenvoudige en intuïtieve syntaxis, waardoor het gemakkelijk is om te leren en te gebruiken, zelfs voor gebruikers die nog niet aan tests hebben gewerkt.

De tests van UI lopen als kwaliteitsgate in het Testen van de Douane UI stap-vereist in ​ productiepijpleidingen ​, facultatief in ​ niet-productiepijpleidingen ​. Om het even welke tests van de UI met inbegrip van regressie en nieuwe functionaliteiten toelaten om fouten te ontdekken en te melden.

In tegenstelling tot aangepaste functionele tests, die HTTP-tests zijn die in Java zijn geschreven, kunnen UI-tests een Docker-afbeelding zijn. De tests kunnen in om het even welke taal worden geschreven, zolang zij de overeenkomsten volgen die in de sectie ​ worden bepaald de Tests van de Bouw UI ​.

Aan de slag met gebruikersinterfacetests get-started-ui-tests

In deze sectie worden de stappen beschreven die zijn vereist voor het instellen van UI-tests voor uitvoering in Cloud Manager.

Interfacetests maken building-ui-tests

Een Maven project produceert een Docker bouwt context. In deze docker wordt de bouwcontext beschreven hoe u een Docker-afbeelding kunt maken die de UI-tests bevat en die door Cloud Manager wordt gebruikt om een Docker-afbeelding te genereren die de werkelijke UI-tests bevat.

In deze sectie worden de stappen beschreven die nodig zijn om een UI-testproject toe te voegen aan uw opslagplaats.

Een docker Build-context genereren generate-docker-build-context

Om Docker te produceren bouwt context, hebt u een Gemaakt module nodig die:

De eenvoudigste manier is de ​ Gemaakt Insteekmodule van de Assemblage te vormen ​ om het Docker te creëren bouwt contextarchief en wijst het juiste classificatiebureau aan het toe.

U kunt tests UI met verschillende technologieën en kaders bouwen, maar deze sectie veronderstelt dat uw project op een manier gelijkend op het volgende wordt opgemaakt.

├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│   ├── package.json
│   ├── index.js
│   └── wdio.conf.js
└── wait-for-grid.sh

Het bestand pom.xml verzorgt de Maven-build. Voeg een uitvoering aan de Geweven Insteekmodule van de Assemblage toe gelijkend op het volgende.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <configuration>
        <descriptors>
            <descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
        </descriptors>
        <tarLongFileMode>gnu</tarLongFileMode>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Deze uitvoering instrueert de Geweven Insteekmodule van de Assemblage om een archief tot stand te brengen dat op de instructies in assembly-ui-test-docker-context.xml wordt gebaseerd, genoemd een assemblagebeschrijver in het jargon van de insteekmodule. De assemblagebeschrijver maakt een lijst van alle dossiers die deel van het archief moeten uitmaken.

<assembly>
    <id>ui-test-docker-context</id>
    <includeBaseDirectory>false</includeBaseDirectory>
    <formats>
        <format>tar.gz</format>
    </formats>
    <fileSets>
        <fileSet>
            <directory>${basedir}</directory>
            <includes>
                <include>Dockerfile</include>
                <include>wait-for-grid.sh</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${basedir}/test-module</directory>
            <excludes>
                <exclude>node/**</exclude>
                <exclude>node_modules/**</exclude>
                <exclude>reports/**</exclude>
            </excludes>
        </fileSet>
    </fileSets>
</assembly>

De assemblagedescriptor geeft de plug-in de instructie een archief van het type .tar.gz te maken en wijst er de classificator ui-test-docker-context aan toe. Bovendien worden de bestanden weergegeven die in het archief moeten worden opgenomen, waaronder:

De assemblagebeschrijver sluit ook sommige dossiers uit die terwijl het runnen van de tests UI plaatselijk zouden kunnen worden geproduceerd. Dit garandeert een kleiner archief en snellere builds.

Cloud Manager neemt automatisch het Docker build-context archive op en bouwt het testbeeld tijdens plaatsingspijpleidingen. Uiteindelijk voert Cloud Manager de Docker-afbeelding uit om de UI-tests op uw toepassing uit te voeren.

De build moet nul of één archief produceren. Als het nul archieven produceert, gaat de teststap door gebrek over. Als de build meer dan één archief produceert, is het geselecteerde archief niet-deterministisch.

Klanten kiezen customer-opt-in

Cloud Manager kan uw UI-tests alleen uitvoeren als u zich aanmeldt voor deze functie door een bestand aan uw opslagplaats toe te voegen.

De UI-tests worden uitgevoerd en uitgevoerd als dit bestand niet aanwezig is.

Als u een testing.properties -bestand wilt opnemen in het constructieartefact, voegt u een include -instructie toe in het assembly-ui-test-docker-context.xml -bestand.

[...]
<includes>
    <include>Dockerfile</include>
    <include>wait-for-grid.sh</include>
    <include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]

Als u de voorbeelden gebruikt die door Adobe worden geleverd:

Tests voor gebruikersinterface schrijven writing-ui-tests

Deze sectie beschrijft de overeenkomsten die het beeld van de Docker dat uw tests UI bevat moet volgen. De Docker-afbeelding is gemaakt op basis van de constructiecontext van Docker die in de vorige sectie is beschreven.

Omgevingsvariabelen environment-variables

De volgende omgevingsvariabelen worden bij uitvoering aan de Docker-afbeelding doorgegeven, afhankelijk van uw framework.

* these values will be empty if there is no publish instance

De Adobe-testmonsters bieden hulpfuncties voor toegang tot de configuratieparameters:

Cypress: de standaardfunctie gebruiken Cypress.env('VARIABLE_NAME')

Testrapporten genereren generate-test-reports

De Docker-afbeelding moet testrapporten genereren in de XML-indeling JUnit en deze opslaan in het pad dat is opgegeven door de omgevingsvariabele REPORTS_PATH . De indeling JUnit XML is een veelgebruikte indeling voor het rapporteren van de resultaten van tests. Als het beeld van de Docker Java en Geweven gebruikt, kunnen de standaardtestmodules zoals ​ Gemaakte Steven Stevige Insteekmodule ​ en ​ Geweven Insteekmodule Failsafe ​ dergelijke rapporten uit de doos produceren.

Als het Docker-beeld samen met andere programmeertalen of testrunners wordt geïmplementeerd, controleert u de documentatie voor de gekozen hulpmiddelen op hoe u JUnit-XML-rapporten kunt genereren.

Vereisten prerequisites

Seleniumspecifieke details

Wachten op klaar voor selenium waiting-for-selenium

Alvorens de tests beginnen, is het de verantwoordelijkheid van het beeld van de Docker om ervoor te zorgen dat de server van Selenium in gebruik is. Wachten op de seleniumservice is een proces in twee stappen.

Zodra het statuseindpunt van Selenium met een positieve reactie beantwoordt, kunnen de tests beginnen.

Voor Adobe UI-testvoorbeelden wordt wait-for-grid.sh gebruikt. Het loopt bij het begin van de Dokker en lanceert tests slechts nadat het net klaar is.

Schermafbeeldingen en video's vastleggen capture-screenshots

De Docker-afbeelding kan aanvullende testuitvoer genereren (bijvoorbeeld schermafbeeldingen of video's) en deze opslaan in het pad dat wordt aangegeven door de omgevingsvariabele REPORTS_PATH . Alle bestanden die onder REPORTS_PATH worden gevonden, worden opgenomen in het archief met testresultaten.

Met de testvoorbeelden die standaard door Adobe worden geleverd, maakt u schermafbeeldingen voor elke mislukte test.

U kunt de hulpfuncties gebruiken om schermafbeeldingen tot stand te brengen door uw tests.

Als een archief van het testresultaat tijdens een UI testuitvoering wordt gecreeerd, kunt u het van Cloud Manager downloaden door de Download Details knoop onder de het Testen van de Douane UI stap ​ te klikken.

Bestanden uploaden upload-files

Tests moeten soms bestanden uploaden naar de toepassing die wordt getest. Om de implementatie van Selenium flexibel te houden ten opzichte van uw tests, is het niet mogelijk om een middel rechtstreeks naar Selenium te uploaden. In plaats daarvan moet u de volgende stappen uitvoeren om een bestand te uploaden.

Cypersspecifieke details

HTTP-proxy instellen

Het ingangspunt van de Docker-container moet de waarde van de omgevingsvariabele PROXY_HOST controleren.

Als deze waarde leeg is, zijn geen extra stappen vereist en de tests zouden zonder een volmacht van HTTP moeten worden uitgevoerd.

Als het niet leeg is, moet het entryPoint manuscript:

Een voorbeeldimplementatie kan in het Centrum van de Test van de Steekproef van de Cypress van de Module op ​ GitHub ​ worden gevonden.

Specifieke gegevens voor afspelen

HTTP-proxy instellen

Net als bij Cypress moeten tests de HTTP-proxy gebruiken als een niet-lege PROXY_HOST omgevingsvariabele wordt opgegeven.

In dat geval moeten de volgende wijzigingen worden aangebracht.

Dockerfile

Installeer cURL en libnss3-tools met certutil.

RUN apt -y update \
    && apt -y --no-install-recommends install curl libnss3-tools \
    && rm -rf /var/lib/apt/lists/*

EnterPoint-script

Neem een basscript op dat, voor het geval PROXY_HOST environment variable wordt gegeven, het volgende doet:

Voorbeeldimplementatie:

# setup proxy environment variables and CA certificate
if [ -n "${PROXY_HOST:-}" ]; then
  if [ -n "${PROXY_HTTPS_PORT:-}" ]; then
    export HTTP_PROXY="https://${PROXY_HOST}:${PROXY_HTTPS_PORT}"
  elif [ -n "${PROXY_HTTP_PORT:-}" ]; then
    export HTTP_PROXY="http://${PROXY_HOST}:${PROXY_HTTP_PORT}"
  fi
  if [ -n "${PROXY_CA_PATH:-}" ]; then
    echo "installing certificate"
    mkdir -p $HOME/.pki/nssdb
    certutil -d sql:$HOME/.pki/nssdb -A -t "CT,c,c" -n "EaaS Client Proxy Root" -i $PROXY_CA_PATH
    export NODE_EXTRA_CA_CERTS=${PROXY_CA_PATH}
  fi
  if [ -n "${PROXY_OBSERVABILITY_PORT:-}" ] && [ -n "${HTTP_PROXY:-}" ]; then
    echo "waiting for proxy"
    curl --silent  --retry ${PROXY_RETRY_ATTEMPTS:-3} --retry-connrefused --retry-delay ${PROXY_RETRY_DELAY:-10} \
      --proxy ${HTTP_PROXY} --proxy-cacert ${PROXY_CA_PATH:-""} \
      ${PROXY_HOST}:${PROXY_OBSERVABILITY_PORT}
    if [ $? -ne 0 ]; then
      echo "proxy is not ready"
      exit 1
    fi
  fi
fi

Configuratie afspelen

Wijzig de afspeelrechterconfiguratie (bijvoorbeeld in playwright.config.js ) om een proxy te gebruiken voor het geval dat de omgevingsvariabele HTTP_PROXY wordt ingesteld.

Voorbeeldimplementatie:

const proxyServer = process.env.HTTP_PROXY || ''

// enable proxy if set
if (proxyServer !== '') {
 cfg.use.proxy = {
  server: proxyServer,
 }
}

UI-tests lokaal uitvoeren run-ui-tests-locally

Alvorens tests UI in een pijpleiding van Cloud Manager te activeren, adviseert Adobe dat u de tests UI plaatselijk tegen ​ SDK van AEM as a Cloud Service ​ in werking stelt. Of u voert de bewerking uit tegen een AEM as a Cloud Service-instantie.

Monster van Cypress-test cypress-sample

JavaScript WebdriverIO-testvoorbeeld javascript-sample

Voorbeeld van afspeelrechttest playwright-sample

Java Selenium WebDriver Test Sample java-sample