Show Menu
SUJETS×

Présentation des résultats de test

Les exécutions du pipeline Cloud Manager for Cloud Services prennent en charge l’exécution de tests sur l’environnement d’évaluation. Cela contraste avec les tests exécutés dans le cadre de l’étape Test de création et d’unité, qui sont réalisés hors ligne, sans aucun accès à un environnement AEM actif. Deux types de tests sont exécutés dans ce contexte :
  • Tests écrits par le client
  • Tests écrits par Adobe
Ces deux types de tests sont exécutés dans une infrastructure en conteneur conçue à cet effet.

Test de qualité du code

Dans le cadre du pipeline, le code source est analysé afin de garantir que les déploiements respectent certains critères de qualité. Actuellement, cette analyse est implémentée par une combinaison de SonarQube et d’examens au niveau du package de contenu à l’aide de OakPAL. Il existe plus de 100 règles combinant des règles Java génériques et des règles spécifiques à AEM. Le tableau suivant résume l’évaluation des critères de test :
Nom
Définition
Catégorie
Seuil d’échec
Cote de sécurité
A = 0 vulnérabilité
B = au moins 1 vulnérabilité mineure
C = au moins 1 vulnérabilité majeure
D = au moins 1 vulnérabilité critique
E = au moins 1 vulnérabilité de blocage
Critique
< B
Cote de fiabilité
A = 0 bogue
B = au moins 1 bogue mineur
C = au moins 1 bogue majeur
D = au moins 1 bogue critique E = au moins 1 bogue bloqueur
Important
< C
Évaluation de maintenabilité
Le coût de correction en suspens pour les smells du code est :
  • <=5% du temps qui s’est déjà écoulé dans l’application, la note est A
  • entre 6 et 10 % la note est B
  • entre 11 et 20 % la note est C
  • entre 21 et 50 % la note est D
  • tout ce qui dépasse 50 % est E
Important
< A
Couverture
Combinaison de couverture de ligne de tests unitaires et de couverture de condition utilisant cette formule :
Coverage = (CT + CF + LC)/(2*B + EL)
où : CT = conditions qui ont été évaluées comme « vrai » au moins une fois lors de l’exécution de tests unitaires
CF = conditions qui ont été évaluées comme « faux » au moins une fois
LC = lignes couvertes = lines_ to_ cover - uncover_ lines
B = nombre total de conditions
EL = nombre total de lignes exécutables (lines_to_cover)
Important
< 50%
Tests unitaires ignorés
Nombre de tests unitaires ignorés.
Infos
> 1
Problèmes en cours
Types de problèmes généraux - Vulnérabilités, bogues et smells de code
Infos
> 0
Lignes dupliquées
Nombre de lignes impliquées dans des blocs dupliqués.
Pour qu’un bloc de code soit considéré comme dupliqué :
  • Projets non Java :
  • Il doit y avoir au moins 100 jetons successifs et dupliqués.
  • Ces jetons doivent être répartis au moins sur :
  • 30 lignes de code pour COBOL
  • 20 lignes de code pour ABAP
  • 10 lignes de code pour d’autres langages
  • Projets Java :
  • Il devrait y avoir au moins 10 instructions successives et dupliquées, quel que soit le nombre de jetons et de lignes.
Les différences dans la mise en retrait ainsi que dans les littéraux de chaîne sont ignorées lors de la détection des doublons.
Infos
> 1%
Compatibilité Cloud Service
Nombre de problèmes de compatibilité Cloud Services identifiés.
Infos
> 0
Pour des définitions plus détaillées, consultez Définitions des mesures .
Vous pouvez télécharger la liste des règles ici : code-quality-rules.xlsx .
Pour en savoir plus sur les règles de qualité du code personnalisé exécutées par Cloud Manager, reportez-vous à la section Règles de qualité du code personnalisé .

Traitement des faux positifs

Le processus d’analyse de qualité n’est pas parfait et identifiera parfois de manière incorrecte des problèmes qui ne sont pas réellement problématiques. On parle alors de « faux positif ».
Dans ce cas, une annotation Java @SuppressWarnings standard spécifiant l’ID de règle comme attribut d’annotation peut être inscrite dans le code source. Par exemple, la règle SonarQube permettant de détecter les mots de passe codés en dur peut être agressive sur la façon dont un mot de passe codé en dur est identifié.
Pour prendre un exemple spécifique, ce code serait assez courant dans un projet AEM qui comporte un code pour se connecter à un service externe :
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube lèvera alors une vulnérabilité de bloqueur. Après avoir examiné le code, vous identifiez qu’il ne s’agit pas d’une vulnérabilité et pouvez l’annoter avec l’identifiant de règle approprié.
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

En revanche, si le code était le suivant :
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

La bonne solution consiste alors à supprimer le mot de passe codé en dur.
Bien qu’il soit préférable de rendre l’annotation @SuppressWarnings aussi précise que possible, c’est-à-dire de n’annoter que l’énoncé ou le bloc qui cause le problème, il est tout de même possible de le faire à un niveau qui se rapporte à la classe.

Écriture de tests fonctionnels

Les tests fonctionnels écrits par le client doivent être placés dans un fichier JAR distinct produit par la même version de Maven que les artefacts à déployer dans AEM. En règle générale, il s’agit d’un module Maven distinct. Le fichier JAR obtenu doit contenir toutes les dépendances requises. Il est généralement créé avec le plug-in Assembly de Maven à l’aide du descripteur jar-with-dependencies.
En outre, l’en-tête de manifeste Cloud-Manager-TestType du fichier JAR doit être défini sur integration-test. Il est prévu que d’autres valeurs d’en-tête soient prises en charge à l’avenir. Voici un exemple de configuration pour le plug-in Assembly de Maven :
<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>

Dans ce fichier JAR, les noms de classe des tests à exécuter doivent se terminer par IT.
Par exemple, une classe nommée com.myco.tests.aem.ExampleIT sera exécutée, mais pas une classe nommée com.myco.tests.aem.ExampleTest .
Les classes de test doivent être des tests JUnit normaux. L’infrastructure de test est conçue et configurée pour être compatible avec les conventions utilisées par la bibliothèque de tests aem-testing-clients. Les développeurs sont vivement encouragés à utiliser cette bibliothèque et à suivre les bonnes pratiques en vigueur. Pour plus d’informations, voir Lien Git .

Tests fonctionnels personnalisés

L’étape des tests fonctionnels personnalisés du pipeline est toujours présente et ne peut pas être ignorée.
Cependant, si aucun fichier JAR de test n’est généré par la compilation, le test réussit par défaut. Actuellement, cette étape est effectuée immédiatement après le déploiement intermédiaire.
le bouton Télécharger le journal permet d’accéder à un fichier ZIP contenant les journaux du formulaire détaillé d’exécution du test. Ces journaux ne contiennent pas les journaux du processus d’exécution AEM proprement dit. Vous pouvez y accéder à l’aide de la fonctionnalité de téléchargement standard ou d’affichage des dernières lignes des journaux. Pour plus d’informations, reportez-vous à la section Accès et gestion des journaux .

Exécution locale du test

Les classes de test étant des tests JUnit, elles peuvent être exécutées à partir d’IDE Java standard comme Eclipse, IntelliJ, NetBeans, etc.
Cependant, lors de l’exécution de ces tests, il est nécessaire de définir diverses propriétés système attendues par aem-testing-clients (et les clients de test Sling sous-jacents).
Les propriétés système sont les suivantes :
  • 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