Test de qualité du code

Le test de qualité du code évalue la qualité du code de votre application. Il s’agit de l’objectif principal d’un pipeline dédié uniquement à la qualité du code. Cette étape est exécutée immédiatement après l’étape de création dans tous les pipelines, aussi bien en production que hors production.

Voir Configuration de votre pipeline CI-CD pour en savoir plus sur les différents types de pipelines.

Compréhension des règles de qualité du code

Au cours du test de qualité du code, le code source est analysé afin de s’assurer qu’il répond à 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 d’OakPAL. Il existe plus de 100 règles combinant des règles Java génériques et des règles spécifiques à AEM. Certaines des règles spécifiques à AEM sont créées en fonction des bonnes pratiques de l’équipe d’ingénierie AEM et sont appelées Règles de qualité du code personnalisées.

REMARQUE

Vous pouvez télécharger la liste complète des règles ici.

Point de contrôle à trois niveaux

Cette étape du test de qualité du code comporte une structure à trois niveaux pour les problèmes identifiés :

  • Critique : il s’agit des problèmes identifiés par le point de contrôle qui entraînent l’échec immédiat du pipeline.

  • Important : il s’agit des problèmes identifiés par le point de contrôle qui entraînent la suspension du pipeline. Un responsable de déploiement, un responsable de projet ou un propriétaire d’entreprise peuvent soit contourner les problèmes, auquel cas le pipeline continue, soit accepter les problèmes, auquel cas le pipeline s’arrête avec un échec.

  • Informations : il s’agit des problèmes identifiés par le point de contrôle qui sont fournis uniquement à titre d’information et qui n’ont aucune incidence sur l’exécution du pipeline.

Les résultats de cette étape sont fournis sous forme de notes.

Le tableau suivant résume les notes et les seuils d’échec pour chacune des catégories Critique, Important et Informations :

Nom Définition Catégorie Seuil d’échec
Note 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
Note 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
Note 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 Service identifiés. Infos > 0
REMARQUE

Pour des définitions plus détaillées, consultez Définitions des mesures.

REMARQUE

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.

REMARQUE

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.

REMARQUE

Bien qu’il n’existe pas d’étape de test de sécurité explicite, des règles de qualité du code liées à la sécurité sont toujours évaluées à l’étape de qualité du code. Pour en savoir plus sur la sécurité dans Cloud Service, reportez-vous à Aperçu de la sécurité pour AEM as a Cloud Service.

Sur cette page