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 Managerom vlotte updates aan douanetoepassingen te verzekeren. Met name ondersteunen IT-testpoorten al het maken en automatiseren van aangepaste tests met behulp van 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 Archieftype van het Project van de AEM te gebruiken.

Adobe stimuleert het gebruik van Cypress, omdat deze in real time opnieuw laden en automatisch wachten biedt, wat tijd bespaart en de 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 mensen die nog niet aan tests hebben gewerkt.

De tests UI worden uitgevoerd als deel van een specifieke kwaliteitsgate voor elke pijpleiding van Cloud Manager met het Testen van de Douane UI van de a ​ stapin productiepijpleidingenof naar keuze 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 douane functionele tests, die de tests zijn van HTTP in Java worden geschreven, kunnen de tests UI een beeld van de Docker met tests zijn die 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.

Ui-tests maken building-ui-tests

Een Maven-project genereert een Docker-buildcontext. In de context van deze Docker-build wordt beschreven hoe u een Docker-afbeelding kunt maken met de UI-tests die Door Cloud Manager wordt gebruikt om een Docker-afbeelding te genereren met daarin de daadwerkelijke UI-tests.

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 om dit te doen is de Gemaakt Insteekmodule van de Assemblage te vormenom 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.

Het archief met de Docker-build-context wordt automatisch opgepakt door Cloud Manager, dat het Docker-image met uw tests zal maken tijdens de implementatiepijplijnen. Uiteindelijk zal Cloud Manager het Docker-beeld in werking stellen om de tests UI tegen 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 verstrekt:

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.

De testmonsters van de Adobe verstrekken helperfuncties om tot de configuratieparameters toegang te hebben:

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 Insteekmoduleen Geweven Insteekmodule Failsafedergelijke 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.

De de teststeekproeven van UI van de Adobe behandelen dit met het manuscript wait-for-grid.sh, dat bij het opstarten van Docker wordt uitgevoerd en de daadwerkelijke testuitvoering begint slechts zodra 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 is opgegeven door de omgevingsvariabele REPORTS_PATH. Elk bestand dat u hieronder REPORTS_PATH vindt, wordt opgenomen in het archief van de testresultaat.

De testvoorbeelden die door Adobe worden geleverd, maken standaard schermafbeeldingen voor elke mislukte test.

U kunt de helperfuncties gebruiken om screenshots te maken tijdens uw tests.

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

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 de volmacht van HTTP moeten worden uitgevoerd.

Als het niet leeg is, moet het entryPoint manuscript:

Een voorbeeld-implementatie vindt u in het entrypoint van de module Cypress Sample Test op GitHub.

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.

Daartoe 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 het om de tests UI plaatselijk tegen AEM as a Cloud Service SDKof tegen een daadwerkelijke instantie van AEM as a Cloud Service in werking te stellen.

Monster van Cypress-test cypress-sample

Voorbeeld van JavaScript-webdriverIO-test javascript-sample

Java Selenium WebDriver Test Sample java-sample