Teste de qualidade do código

O Teste de qualidade do código avalia a qualidade do código de seu aplicativo. É o objetivo principal de um pipeline somente de qualidade de código e é executado imediatamente após a etapa de build em todos os pipelines de não produção e produção.

Consulte Configuração do pipeline de CI-CD para saber mais sobre diferentes tipos de pipelines.

Noções básicas sobre regras de qualidade de código

Em Teste de qualidade do código, o código-fonte é digitalizado para garantir que atenda a determinados critérios de qualidade. Atualmente, isto é implementado através de uma combinação de SonarQube e exame de nível de pacote de conteúdo usando OakPAL. Há mais de 100 regras que combinam regras Java genéricas e regras específicas de AEM. Algumas das regras específicas do AEM são criadas com base nas práticas recomendadas da engenharia AEM e são chamadas de Regras de qualidade do código personalizado.

OBSERVAÇÃO

Você pode baixar a lista completa de regras here.

Porta de três níveis

Há uma estrutura de três níveis nesta etapa de teste de qualidade de código para os problemas identificados:

  • Crítico: Esses são problemas identificados pela porta que causam uma falha imediata do pipeline.

  • Importante: Esses são problemas identificados pela porta que fazem com que o pipeline entre em um estado pausado. Um gerente de implantação, gerente de projeto ou proprietário de negócios pode substituir os problemas, caso o pipeline continue, ou pode aceitar os problemas, caso o pipeline pare com uma falha.

  • Informações: Esses são problemas identificados pela porta, que são fornecidos apenas para fins informativos e não têm impacto na execução do pipeline

Os resultados desta etapa são fornecidos como Classificações.

A tabela a seguir resume as classificações e os limiares de falha para cada uma das categorias Crítica, Importante e Informações:

Nome Definição Categoria Limite de Falhas
Classificação de segurança A = 0 Vulnerabilidade
B = pelo menos 1 Vulnerabilidade Menor
C = pelo menos 1 Vulnerabilidade Principal
D = pelo menos 1 Vulnerabilidade Crítica
E = pelo menos 1 Vulnerabilidade do Bloqueador
Crítico < B
Classificação da confiabilidade A = 0 Bug
B = pelo menos 1 Bug menor
C = pelo menos 1 Bug Major
D = pelo menos 1 Bug Crítico E = pelo menos 1 Bug Bloqueador
Importante < C
Classificação da capacidade de manutenção O custo excepcional da correção para cheiros de código é:
  • <=5% do tempo que já entrou no aplicativo, a classificação é A
  • entre 6 e 10%, a classificação é de
  • entre 11 e 20% a classificação é de C
  • entre 21 e 50%, a classificação é de D
  • qualquer coisa acima de 50% é um E
Importante < A
Cobertura Uma combinação da cobertura da linha de ensaio da unidade e da cobertura da condição utilizando esta fórmula:
Coverage = (CT + CF + LC)/(2*B + EL)
em que: CT = condições que foram avaliadas como 'true' pelo menos uma vez durante a execução de testes de unidade
CF = condições que foram avaliadas como 'false' pelo menos uma vez durante a execução de testes de unidade
LC = linhas cobertas = linhas_to_cover - linhas_não cobertas

B = número total de condições
EL = número total de linhas executáveis (lines_to_cover)
Importante < 50%
Testes de Unidade Ignorados Número de testes de unidade ignorados. Informações > 1
Problemas em aberto Tipos de problemas gerais - Vulnerabilidades, Erros e Cheiros de código Informações > 0
Linhas Duplicadas Número de linhas envolvidas em blocos duplicados.
Para que um bloco de código seja considerado como duplicado:
  • Projetos não Java:
  • Deve haver pelo menos 100 tokens sucessivos e duplicados.
  • Esses tokens devem ser distribuídos pelo menos em:
  • 30 linhas de código para COBOL
  • 20 linhas de código para ABAP
  • 10 linhas de código para outras línguas
  • Projetos Java:
  • Deve haver pelo menos 10 declarações sucessivas e duplicadas, independentemente do número de tokens e linhas.

As diferenças no recuo, bem como nos literais de string são ignoradas ao detectar duplicações.
Informações > 1%
Compatibilidade Cloud Service Número de problemas de compatibilidade de Cloud Service identificados. Informações > 0
OBSERVAÇÃO

Consulte Definições de Métricas para obter definições mais detalhadas.

OBSERVAÇÃO

Para saber mais sobre as regras de qualidade do código personalizado executadas pelo Cloud Manager, consulte Regras de qualidade do código personalizado.

Lidar com falsos positivos

O processo de verificação da qualidade não é perfeito e, por vezes, identifica incorretamente questões que não são realmente problemáticas. Isso é chamado de falso positivo.

Nesses casos, o código-fonte pode ser anotado com o Java padrão @SuppressWarnings anotação especificando a ID da regra como o atributo de anotação. Por exemplo, um problema comum é que a regra SonarQube para detectar senhas codificadas pode ser agressiva sobre como uma senha codificada é identificada.

Para observar um exemplo específico, esse código seria bastante comum em um projeto AEM que tem código para se conectar a algum serviço externo:

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube aumentará a Vulnerabilidade do Bloqueador. Após revisar o código, você identifica que isso não é uma vulnerabilidade e pode anotar com a ID de regra apropriada.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

No entanto, por outro lado, se o código era realmente este:

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

Em seguida, a solução correta é remover a senha codificada.

OBSERVAÇÃO

Embora seja uma prática recomendada fazer a variável @SuppressWarnings anotação o mais específica possível, ou seja, anote apenas a declaração ou bloco específico que causa o problema, é possível anotar em nível de classe.

OBSERVAÇÃO

Embora não haja uma etapa explícita de Teste de segurança, ainda há regras de qualidade de código relacionadas à segurança avaliadas durante a etapa de qualidade do código. Consulte Visão geral de segurança para AEM as a Cloud Service para saber mais sobre segurança no Cloud Service.

Nesta página