Test funzionale

Il test funzionale è suddiviso in due tipi:

• Test funzionale del prodotto
• Test funzionale personalizzato

Test funzionale del prodotto

I test funzionali di prodotto sono una serie di test di integrazione HTTP (IT) stabili attorno alle funzionalità di base in AEM (ad esempio, creazione e replica) che impediscono la distribuzione delle modifiche apportate dal cliente al codice dell'applicazione in caso di interruzione di questa funzionalità di base.

I test funzionali del prodotto vengono eseguiti automaticamente ogni volta che un cliente distribuisce il nuovo codice a Cloud Manager e non può essere ignorato.

Per i test di esempio, fare riferimento a Test funzionali del prodotto.

Test funzionale personalizzato

Il passaggio di test funzionale personalizzato nella pipeline è sempre presente e non può essere ignorato.

Tuttavia, se la build non produce JAR di prova, il test viene superato per impostazione predefinita.

Scrittura di test funzionali

I test funzionali scritti dal cliente devono essere confezionati come file JAR separato prodotto dalla stessa build Maven degli artefatti da distribuire a AEM. Generalmente questo sarebbe un modulo Maven separato. Il file JAR risultante deve contenere tutte le dipendenze richieste e generalmente viene creato utilizzando il plug-in maven-assembly utilizzando il descrittore jar-with-dependencies.

Inoltre, il JAR deve avere l’intestazione del manifesto di Cloud-Manager-TestType impostata su integration-test. In futuro, saranno supportati ulteriori valori di intestazione. Un esempio di configurazione per il plug-in maven-assembly è:

<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

All'interno di questo file JAR, i nomi delle classi dei test effettivi da eseguire devono terminare con l'IT.

Ad esempio, una classe denominata com.myco.tests.aem.ExampleIT viene eseguita ma non una classe denominata com.myco.tests.aem.ExampleTest.

Le classi di test devono essere normali test JUnit. L'infrastruttura di test è progettata e configurata per essere compatibile con le convenzioni utilizzate dalla libreria di test dei client Aem-testing. Gli sviluppatori sono invitati a utilizzare questa libreria e a seguire le procedure ottimali. Per ulteriori informazioni, fare riferimento a Collegamento alla griglia.

Esecuzione test locale

Poiché le classi di test sono test JUnit, possono essere eseguite da IDE Java mainstream come Eclipse, IntelliJ, NetBeans e così via.

Tuttavia, durante l'esecuzione di questi test, sarà necessario impostare una serie di proprietà del sistema previste dai client Aem-testing (e dai client Sling Testing sottostanti).

Le proprietà del sistema sono le seguenti:

• sling.it.instances - should be set to 2
• sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
• sling.it.instance.runmode.1 - should be set to author
• sling.it.instance.adminUser.1 - should be set to the author admin user, e.g. admin
• sling.it.instance.adminPassword.1 - should be set to the author admin password
• sling.it.instance.url.2 - should be set to the author URL, for example, http://localhost:4503
• sling.it.instance.runmode.2 - should be set to publish
• sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
• sling.it.instance.adminPassword.2 - should be set to the publish admin password