Utilizamos activamente la plataforma en nuestro trabajo. SonarQube para mantener la calidad del código en un alto nivel. Al integrar uno de los proyectos escritos en VueJs+Mecanografiado, surgieron problemas. Por eso, me gustaría contaros con más detalle cómo logramos solucionarlos.

En este artículo hablaremos, como escribí anteriormente, de la plataforma SonarQube. Un poco de teoría: qué es en general, para aquellos que oyen hablar de él por primera vez:

SonarQube (anterior Sonar) es una plataforma de código abierto para inspección continua y medición de la calidad del código.
Admite análisis de código y detección de errores de acuerdo con las reglas de programación MISRA C, MISRA C++, MITRE/CWE y CERT Secure Coding Standards. También puede reconocer errores de las listas de errores de programación OWASP Top 10 y CWE/SANS Top 25.
A pesar de que la plataforma utiliza varias herramientas listas para usar, SonarQube reduce los resultados a un único panel, manteniendo un historial de ejecuciones y permitiendo así ver la tendencia general de los cambios en la calidad del software durante el desarrollo.

Más detalles se pueden encontrar en el sitio web oficial

Se admite una gran cantidad de lenguajes de programación. A juzgar por la información del enlace anterior, se trata de más de 25 idiomas. Para admitir un idioma específico, debe instalar el complemento adecuado. La versión comunitaria incluye un complemento para trabajar con Javascript (incluidos los mecanografiados), aunque la wiki dice lo contrario. Detrás Javascript respuestas del complemento SonarJS, para mecanografiado SonarTS respectivamente.

El cliente oficial sirve para enviar información de cobertura. escáner-sonarqube, que, utilizando la configuración de config-file, envía estos datos al servidor SonarQube para una mayor consolidación y agregación.

para Javascript есть contenedor npm. Entonces, comencemos la implementación paso a paso. SonarQube в Vista-proyecto usando Mecanografiado.

Para implementar un servidor SonarQube aprovechemos docker-componer.

sonar.yaml:

version: '1'
    services:
        simplesample-sonar:
            image: sonarqube:lts
            ports:
                - 9001:9000
                - 9092:9092
            network_mode: bridge

Lanzar:

docker-compose -f sonar.yml up

Después de eso SonarQube estará disponible en: http://localhost:9001 .

Todavía no hay proyectos al respecto y eso es justo. Corregiremos esta situación. Tomé el proyecto de ejemplo oficial para VueJS+TS+Jest. Inclinémoslo hacia nosotros mismos:

git clone https://github.com/vuejs/vue-test-utils-typescript-example.git

Primero necesitamos instalar el cliente. SonarQubeque se llama escáner-sonarpara npm hay un envoltorio:

yarn add sonarqube-scanner

E inmediatamente agregue el comando a guiones para trabajar con ello.

paquete.json:

{
 … 
   scripts: {
      ...
      "sonar": "sonar-scanner"
      ...
   },
 …
}

A continuación, para que el escáner funcione, debe configurar la configuración del proyecto en un archivo especial. Empecemos con lo básico.

sonar-proyecto.propiedades:

sonar.host.url=http://localhost:9001

sonar.projectKey=test-project-vuejs-ts
sonar.projectName=Test Application (VueJS+TS)

sonar.sources=src
# sonar.tests=
sonar.test.inclusions=src/**/*tests*/**
sonar.sourceEncoding=UTF-8

sonar.host.url - DIRECCIÓN Sonar'A;
sonar.projectKey – identificador de proyecto único en el servidor Sonar'A;
sonar.nombredelproyecto – su nombre, se puede cambiar en cualquier momento, ya que el proyecto se identifica por clave del proyecto;
sonar.fuentes – carpeta con fuentes, generalmente esta src, pero puede ser cualquier cosa. Esta carpeta se configura en relación con la carpeta raíz, que es la carpeta desde la que se inicia el escáner;
pruebas.sonar – un parámetro que va en conjunto con el anterior. Esta es la carpeta donde se encuentran las pruebas. En este proyecto, no existe dicha carpeta y la prueba se encuentra junto al componente que se está probando en la carpeta 'test', así que lo ignoraremos por ahora y usaremos el siguiente parámetro;
inclusiones.de.prueba.de.sonar – ruta para pruebas que utilizan una máscara, puede haber varios elementos enumerados separados por comas;
sonar.sourceCodificación – codificación de archivos fuente.

Para el primer lanzamiento del escáner, todo está listo, excepto la acción principal anterior: iniciar el propio motor de pruebas, para que pueda generar información sobre la cobertura, que el escáner utilizará posteriormente.

Pero para hacer esto, necesita configurar el motor de prueba para generar esta información. En este proyecto, el motor de prueba es Broma. Y su configuración está en la sección correspondiente del archivo. package.json.

Agreguemos estas configuraciones:

"collectCoverage": true,
"collectCoverageFrom": [
      "src/**/*",
      "!src/main.ts",
      "!src/App.vue",
      "!src/**/*.d.*",
      "!src/**/*__tests__*"
],

Es decir, establecemos la bandera en sí para la necesidad de calcular la cobertura y la fuente (junto con las excepciones) a partir de la cual se formará.

Ahora ejecutemos la prueba:

yarn test

Veremos lo siguiente:

La razón es que no hay código en el componente en sí. Arreglemos esto.

HolaMundo.vue:

...
methods: {
    calc(n) {
      return n + 1;
    }
  },
mounted() {
  this.msg1 = this.msg + this.calc(1);
},
...

Esto será suficiente para calcular la cobertura.

Después de reiniciar la prueba, nos aseguraremos de esto:

En la pantalla deberíamos ver información sobre la cobertura, y se creará una carpeta en la carpeta del proyecto. cobertura con información de cobertura de pruebas en formato universal LCOV (extensión LTP GCOV).

Gcov es una utilidad de distribución gratuita para examinar la cobertura del código. Gcov genera el número exacto de ejecuciones para cada declaración en un programa y le permite agregar anotaciones al código fuente. Gcov viene como una utilidad estándar como parte del paquete GCC.
Lcov - interfaz gráfica para gcov. Reúne archivos gcov para múltiples archivos fuente y produce un conjunto de páginas HTML con código e información de cobertura. También se generan páginas para facilitar la navegación. Lcov admite la cobertura de cadenas, funciones y ramas.

Una vez completadas las pruebas, la información de cobertura se ubicará en cobertura/lcov.info.
Necesitamos decir Sonar'¿De dónde puedo conseguirlo? Por lo tanto, agreguemos las siguientes líneas a su archivo de configuración. Pero hay un punto: los proyectos pueden ser multilingües, es decir, en la carpeta src existen códigos fuente para varios lenguajes de programación y afiliación a uno u otro, y a su vez, el uso de uno u otro complemento viene determinado por su extensión. Y la información de cobertura se puede almacenar en diferentes lugares para diferentes lenguajes de programación, por lo que cada lenguaje tiene su propia sección para configurar esto. Nuestro proyecto utiliza Mecanografiado, por lo que necesitamos una sección de configuración solo para ello:

sonar-proyecto.propiedades:

sonar.typescript.coveragePlugin=lcov
sonar.typescript.lcov.reportPaths=coverage/lcov.info

Todo está listo para el primer lanzamiento del escáner. Me gustaría señalar que el proyecto es SonarSe crea automáticamente la primera vez que ejecuta el escáner para un proyecto determinado. En ocasiones posteriores se acumulará información para ver la dinámica de los cambios en los parámetros del proyecto a lo largo del tiempo.

Entonces, usemos el comando creado anteriormente en package.json:

yarn run sonar

Nota: También puedes usar el parámetro. -X para un registro más detallado.

Si el escáner se inició por primera vez, primero se descargará el binario del escáner. Después de eso, se inicia y comienza a escanear el servidor. Sonar'a para complementos instalados, calculando así el idioma admitido. También se cargan varios otros parámetros para su funcionamiento: perfiles de calidad, reglas activas, repositorio de métricas, reglas del servidor.

Nota: No nos detendremos en ellos en detalle en el marco de este artículo, pero siempre puedes contactar con fuentes oficiales.

A continuación, comienza el análisis de la carpeta. src para la disponibilidad de archivos fuente para todos los idiomas soportados (si no se especifica uno específico), con su posterior indexación.

Luego vienen otros análisis en los que no nos centraremos en este artículo (por ejemplo, linting, detección de duplicación de código, etc.).

Al final del trabajo del escáner, toda la información recopilada se agrega, se archiva y se envía al servidor.

Luego de esto, ya podemos ver lo sucedido en la interfaz web:

Como vemos algo funcionó, e incluso muestra algún tipo de cobertura, pero no coincide con la nuestra. Broma-informe.

Vamos a resolverlo. Veamos el proyecto con más detalle, hagamos clic en el valor de cobertura y "caigamos" en un informe de archivo detallado:

Aquí vemos, además del archivo principal, examinado. HolaMundo.vue, también hay un archivo principal.ts, lo que arruina toda la imagen de la cobertura. Pero ¿por qué lo excluimos del cálculo de la cobertura? Sí, todo está correcto, pero estaba en el nivel. Broma, pero el escáner lo indexó, por lo que terminó en sus cálculos.

Arreglemos esto:

sonar-proyecto.propiedades:

...
sonar.exclusions=src/main.ts
...

Me gustaría hacer una aclaración: además de las carpetas que se especifican en este parámetro, también se agregan todas las carpetas enumeradas en el parámetro. inclusiones.de.prueba.de.sonar.

Después de iniciar el escáner, vemos la información correcta:

Veamos el siguiente punto: Perfiles de calidad. Hablé arriba sobre el soporte. SonarEstoy en varios idiomas al mismo tiempo. Esto es exactamente lo que estamos viendo. Pero sabemos que nuestro proyecto está escrito en TSEntonces, ¿por qué forzar el escáner con manipulaciones y controles innecesarios? Estableceremos el idioma para el análisis agregando un parámetro más al archivo de configuración. Sonar'A:

sonar-proyecto.propiedades:

...
sonar.language=ts
...

Ejecutemos el escáner nuevamente y veamos el resultado:

La cobertura desapareció por completo.

Si miramos el registro del escáner, podemos ver la siguiente línea:

Es decir, nuestros archivos de proyecto simplemente no estaban indexados.

La situación es la siguiente: apoyado oficialmente VueJs está en el complemento SonarJSquien es responsable de Javascript.

Pero este soporte no está en el complemento. SonarTS para TS, sobre el cual se abrió un ticket oficial en el rastreador de errores Sonar'A:

Aquí hay algunas respuestas de uno de los representantes de los desarrolladores de SonarQube, que confirman este hecho.

Pero todo funcionó para nosotros, objetas. Sí lo es, intentémoslo un poco. "cortar a tajos".
si hay apoyo .vue-archivos Sonar'oh, entonces intentemos decirle que los considere como Mecanografiado.

Agreguemos un parámetro:

sonar-proyecto.propiedades:

...
sonar.typescript.file.suffixes=.ts,.tsx,.vue
...

Iniciemos el escáner:

Y listo, todo vuelve a la normalidad, y con un perfil solo para Mecanografiado. Es decir, logramos solucionar el problema en soporte. VueJs+TS para SonarQube.

Intentemos ir más allá y mejorar un poco la información de cobertura.

Lo que hemos hecho hasta ahora:

agregado al proyecto Sonar-escáner;
configuración Broma generar información de cobertura;
configurado Sonar-escáner;
resolvió el problema de soporte .vue-archivos + Mecanografiado.

Además de la cobertura de la prueba, existen otros criterios útiles e interesantes para la calidad del código, por ejemplo, la duplicación del código y el número de líneas (implicadas en el cálculo de los coeficientes relacionados con la complejidad del código) del proyecto.

En la implementación actual del complemento para trabajar con TS (SonarTS) no trabajará CPD (detector de copiar y pegar) y contando líneas de código .vue-archivos.

Para crear una situación sintética de duplicación de código, simplemente duplique el archivo componente con un nombre diferente y agréguelo también al código. principal.ts una función ficticia y duplicarla con un nombre diferente. Para comprobar si hay duplicaciones como en .vuey en .ts -archivos.

principales.ts:

...
function name(params:string): void {
  console.log(params);
}
...

Para hacer esto, necesita comentar temporalmente la línea de configuración:

sonar-proyecto.propiedades:

...
sonar.exclusions=src/main.ts
...

Reiniciemos el escáner junto con las pruebas:

yarn test && yarn run sonar

Por supuesto, nuestra cobertura caerá, pero ahora eso no nos interesa.

En términos de duplicar líneas de código, veremos:

Para comprobarlo usaremos CPD-utilidad - jscpd:

npx jscpd src

Para líneas de código:

Quizás esto se resuelva en futuras versiones del complemento. SonarJS(TS). Me gustaría señalar que gradualmente están comenzando a fusionar estos dos complementos en uno solo. SonarJS, lo cual creo que es correcto.

Ahora quería considerar la opción de mejorar la información de cobertura.

Hasta ahora podemos ver la cobertura de prueba en términos porcentuales para todo el proyecto y para los archivos en particular. Pero es posible ampliar este indicador con información sobre la cantidad unidad-pruebas para el proyecto, así como en el contexto de archivos.

Hay una biblioteca que puede Broma-convertir el informe al formato para Sonar'A:
datos de prueba genéricos - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Instalemos esta biblioteca en nuestro proyecto:

yarn add jest-sonar-reporter

Y añádelo a la configuración. Broma:

paquete.json:

…
"testResultsProcessor": "jest-sonar-reporter"
…

Ahora ejecutemos la prueba:

yarn test

Después de lo cual se creará un archivo en la raíz del proyecto. informe-prueba.xml.

Usémoslo en la configuración. Sonar'A:

sonar-proyecto.propiedades:

…
sonar.testExecutionReportPaths=test-report.xml
…

Y reinicie el escáner:

yarn run sonar

Veamos qué ha cambiado en la interfaz. Sonar'A:

Y nada ha cambiado. El caso es que Sonar no considera los archivos descritos en el informe Jest como archivos unidad-pruebas. Para corregir esta situación utilizamos el parámetro de configuración Sonar pruebas.sonar, en el que indicaremos explícitamente las carpetas con pruebas (por ahora solo tenemos una):

sonar-proyecto.propiedades:

…
sonar.tests=src/components/__tests__
…

Reiniciemos el escáner:

yarn run sonar

Veamos qué ha cambiado en la interfaz:

Ahora hemos visto el número de nuestro unidad-tests y, al haber fallado al hacer clic dentro, podemos ver la distribución de este número entre los archivos del proyecto:

Conclusión

Entonces, analizamos una herramienta para el análisis continuo. SonarQube. Integramos con éxito en él un proyecto escrito en VueJs+TS. Se corrigieron algunos problemas de compatibilidad. Aumentamos el contenido de información del indicador de cobertura de la prueba. En este artículo examinamos solo uno de los criterios de calidad del código (quizás uno de los principales), pero SonarQube respalda otros criterios de calidad, incluidas las pruebas de seguridad. Pero no todas estas funciones están completamente disponibles en vibrante e inclusiva-versiones. Una de las características interesantes y útiles es la integración. SonarQube con varios sistemas de gestión de repositorios de código, como GitLab y BitBucket. Para prevenir solicitud de fusión de extracción (fusión)'a a la rama principal del repositorio cuando la cobertura se degrada. Pero esta es una historia para un artículo completamente diferente.

PS: Todo lo descrito en el artículo en forma de código está disponible en mi tenedor.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Utilizas la plataforma SonarQube?

26,3%Sí5
15,8%No3
15,8%Escuché sobre esta plataforma y quiero usar3
10,5%He oído hablar de esta plataforma y no quiero usarla2
0,0%Estoy usando una plataforma diferente0
31,6%Primera vez que oigo hablar de ella6

19 usuarios votaron. 3 usuarios se abstuvieron.

Fuente: habr.com

Integración del proyecto VueJS+TS con SonarQube

Conclusión

¿Utilizas la plataforma SonarQube?

Añadir un comentario Cancelar respuesta