Prueba de calidad de código

La prueba de calidad del código evalúa la calidad del código de la aplicación. Es el objetivo central de una canalización solo de calidad de código y se ejecuta inmediatamente después del paso de compilación en todas las canalizaciones que no sean de producción y producción.

Consulte Configuración de la canalización CI-CD para obtener más información sobre los distintos tipos de canalizaciones.

Comprender las reglas de calidad de código

En la prueba de calidad del código, se analiza el código fuente para asegurarse de que cumple determinados criterios de calidad. Actualmente, esto es implementado por una combinación de SonarQube y el examen de nivel de paquete de contenido usando OakPAL. Hay más de 100 reglas que combinan reglas genéricas de Java y reglas específicas de AEM. Algunas de las reglas específicas del AEM se crean en función de las prácticas recomendadas de AEM ingeniería y se denominan Reglas de calidad de código personalizado.

NOTA

Puede descargar la lista completa de reglas aquí.

Puerta de tres niveles

Hay una estructura de tres niveles en este paso de prueba de calidad de código para los problemas identificados:

  • Importante: Estos son problemas identificados por la puerta que causan un fallo inmediato de la tubería.

  • Importante: Estos son problemas identificados por la puerta que hacen que la canalización introduzca un estado pausado. Un administrador de implementación, un administrador de proyectos o un propietario de empresa pueden anular los problemas, en cuyo caso la canalización continúa, o pueden aceptar los problemas, en cuyo caso la canalización se detiene con un error.

  • Información: Estos son problemas identificados por la puerta que se proporcionan exclusivamente con fines informativos y no tienen impacto en la ejecución de la canalización

Los resultados de este paso se entregan como Clasificaciones.

La siguiente tabla resume las clasificaciones y los umbrales de error para cada una de las categorías Crítica, Importante e Información:

Nombre Definición Categoría Umbral de error
Clasificación de seguridad A = 0 Vulnerabilidad
B = al menos 1 Vulnerabilidad menor
C = al menos 1 Vulnerabilidad mayor
D = al menos 1 Vulnerabilidad crítica
E = al menos 1 Vulnerabilidad del bloqueador
Importante < B
Clasificación de fiabilidad A = 0 Error
B = al menos 1 Error menor
C = al menos 1 Error mayor
D = al menos 1 Error crítico E = al menos 1 Error del bloqueador
Importante < C
Puntuación de mantenimiento El coste de corrección pendiente de los olores de código es:
  • <>
  • entre el 6% y el 10% la calificación es a B
  • entre el 11% y el 20% la calificación es C
  • entre el 21 y el 50 % la calificación es D
  • cualquier valor superior al 50% es una E
Importante < A
Cobertura Una combinación de cobertura de línea de prueba unitaria y cobertura de condición utilizando esta fórmula:
Coverage = (CT + CF + LC)/(2*B + EL)
donde: CT = condiciones que se han evaluado en 'true' al menos una vez al ejecutar pruebas unitarias
CF = condiciones que se han evaluado en 'false' al menos una vez al ejecutar pruebas unitarias
LC = líneas cubiertas = líneas_to_cover - uncovered_lines

B = número total de condiciones
EL = número total de líneas ejecutables (lines_to_cover)
Importante < 50%
Pruebas unitarias omitidas Número de pruebas unitarias omitidas. Información > 1
Problemas abiertos Tipos de problemas generales: Vulnerabilidades, errores y huecos de código Información > 0
Líneas duplicadas Número de líneas involucradas en bloques duplicados.
Para que un bloque de código se considere duplicado:
  • Proyectos que no son de Java:
  • Debe haber al menos 100 tokens sucesivos y duplicados.
  • Estos tokens deben propagarse al menos en:
  • 30 líneas de código para COBOL
  • 20 líneas de código para ABAP
  • 10 líneas de código para otros idiomas
  • Proyectos Java:
  • Debe haber al menos 10 afirmaciones sucesivas y duplicadas, independientemente del número de tokens y líneas.

Las diferencias en la sangría y en los literales de cadena se ignoran al detectar duplicados.
Información > 1%
Compatibilidad del Cloud Service Número de problemas de compatibilidad con Cloud Service identificados. Información > 0
NOTA

Consulte Definiciones de métricas para obtener definiciones más detalladas.

NOTA

Para obtener más información sobre las reglas de calidad de código personalizadas ejecutadas por Cloud Manager, consulte Reglas de calidad de código personalizado.

Tratamiento de falsos positivos

El proceso de digitalización de la calidad no es perfecto y a veces identifica incorrectamente los problemas que no son realmente problemáticos. Esto se conoce como falso positivo.

En estos casos, el código fuente se puede anotar con la anotación estándar Java @SuppressWarnings que especifica el ID de regla como atributo de anotación. Por ejemplo, un problema común es que la regla SonarQube para detectar contraseñas codificadas puede ser agresiva sobre cómo se identifica una contraseña codificada.

Para ver un ejemplo específico, este código sería bastante común en un proyecto AEM que tiene código para conectarse a algún servicio externo:

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

SonarQube entonces generará una vulnerabilidad Blocker. Después de revisar el código, identifique que esta no es una vulnerabilidad y pueda anotarla con el id de regla adecuado.

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

Sin embargo, por otro lado, si el código era realmente así:

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

A continuación, la solución correcta es quitar la contraseña codificada.

NOTA

Aunque se recomienda hacer que la anotación @SuppressWarnings sea lo más específica posible, es decir, anotar solo la sentencia o bloque específico que causa el problema, es posible realizar anotaciones a nivel de clase.

NOTA

Aunque no hay ningún paso explícito de Prueba de seguridad, aún hay reglas de calidad de código relacionadas con la seguridad evaluadas durante el paso de calidad del código. Consulte Security Overview for AEM as a Cloud Service para obtener más información sobre la seguridad en Cloud Service.

En esta página