Nous utilisons activement la plateforme dans notre travail SonarQube pour maintenir la qualité du code à un niveau élevé. Lors de l'intégration d'un des projets écrits en VueJs+Typescript, des problèmes sont apparus. Par conséquent, je voudrais vous expliquer plus en détail comment nous avons réussi à les résoudre.

Dans cet article, nous parlerons, comme je l'ai écrit ci-dessus, de la plateforme SonarQube. Un peu de théorie - de quoi s'agit-il en général, pour ceux qui en entendent parler pour la première fois :

SonarQube (ancien Sonar) est une plateforme open source pour l'inspection continue et la mesure de la qualité du code.
Prend en charge l'analyse du code et la détection des erreurs conformément aux règles de programmation MISRA C, MISRA C++, MITRE/CWE et CERT Secure Coding Standards. Il peut également reconnaître les erreurs des listes d'erreurs de programmation OWASP Top 10 et CWE/SANS Top 25.
Malgré le fait que la plateforme utilise divers outils prêts à l'emploi, SonarQube réduit les résultats à un seul tableau de bord, conservant un historique des exécutions et vous permettant ainsi de voir la tendance générale des changements dans la qualité des logiciels au cours du développement.

Plus de détails peuvent être trouvés sur le site officiel

Un grand nombre de langages de programmation sont pris en charge. À en juger par les informations du lien ci-dessus, il s'agit de plus de 25 langues. Pour prendre en charge une langue spécifique, vous devez installer le plugin approprié. La version communautaire comprend un plugin pour travailler avec javascript (y compris les typesсript), bien que le wiki dise le contraire. Derrière javascript réponses du plugin SonarJS, pour Typescript SonarTS respectivement.

Le client officiel est utilisé pour envoyer des informations de couverture scanner sonarqube, qui, en utilisant les paramètres de config-file, envoie ces données au serveur SonarQube pour une consolidation et une agrégation plus poussées.

Pour javascript il est emballage npm. Commençons donc la mise en œuvre étape par étape SonarQube в Vue-projet utilisant Manuscrit.

Pour déployer un serveur SonarQube profitons-en docker-compose.

sonar.yaml:

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

Lancer:

docker-compose -f sonar.yml up

Par la suite SonarQube sera disponible à : http://localhost:9001 .

Il n’y a pas encore de projets et c’est juste. Nous allons corriger cette situation. J'ai pris l'exemple de projet officiel pour VueJS+TS+Jest. Penchons-le vers nous :

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

Nous devons d'abord installer le client SonarQube, qui est appelé scanner sonar, pour NPM il y a un wrapper :

yarn add sonarqube-scanner

Et ajoutez immédiatement la commande à scripts travailler avec.

package.json :

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

Ensuite, pour que le scanner fonctionne, vous devez définir les paramètres du projet dans un fichier spécial. Commençons par les bases.

projet-sonar.propriétés:

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 - adresse Sonar'UN;
• sonar.projectKey – identifiant unique du projet sur le serveur Sonar'UN;
• sonar.projectName – son nom, il peut être modifié à tout moment, puisque le projet est identifié par clé de projet;
• sonar.sources – dossier avec les sources, généralement celui-ci src, mais cela peut être n'importe quoi. Ce dossier est défini par rapport au dossier racine, qui est le dossier à partir duquel le scanner est lancé ;
• sonar.tests – un paramètre qui va de pair avec le précédent. C'est le dossier où se trouvent les tests. Dans ce projet, un tel dossier n'existe pas et le test se trouve à côté du composant testé dans le dossier 'tester', nous allons donc l'ignorer pour l'instant et utiliser le paramètre suivant ;
• sonar.test.inclusions – chemin pour les tests utilisant un masque, il peut y avoir plusieurs éléments répertoriés séparés par des virgules ;
• sonar.sourceEncodage – encodage des fichiers sources.

Pour le premier lancement du scanner, tout est prêt, à l'exception de l'action principale précédente : lancer le moteur de test lui-même, afin qu'il puisse générer des informations sur la couverture, que le scanner utilisera par la suite.

Mais pour ce faire, vous devez configurer le moteur de test pour générer ces informations. Dans ce projet, le moteur de test est il y a. Et ses paramètres sont dans la section correspondante du fichier package.json.

Ajoutons ces paramètres :

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

Autrement dit, nous définissons lui-même la nécessité de calculer la couverture et la source (ainsi que les exceptions) sur la base de laquelle elle sera formée.

Lançons maintenant le test :

yarn test

Nous verrons ce qui suit :

La raison est qu’il n’y a pas de code dans le composant lui-même. Réparons ça.

HelloWorld.vue :

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

Cela suffira pour calculer la couverture.

Après avoir relancé le test, nous nous assurerons de ceci :

Sur l'écran, nous devrions voir des informations sur la couverture, et un dossier sera créé dans le dossier du projet couverture avec des informations sur la couverture des tests dans un format universel LCOV (extension LTP GCOV).

Gcov est un utilitaire distribué gratuitement pour examiner la couverture du code. Gcov génère le nombre exact d'exécutions pour chaque instruction d'un programme et vous permet d'ajouter des annotations au code source. Gcov est un utilitaire standard faisant partie du package GCC.
Lcov - interface graphique pour gcov. Il assemble des fichiers gcov pour plusieurs fichiers sources et produit un ensemble de pages HTML avec des informations de code et de couverture. Des pages sont également générées pour faciliter la navigation. Lcov prend en charge la couverture des chaînes, des fonctions et des branches.

Une fois les tests terminés, les informations de couverture seront situées dans couverture/lcov.info.
Nous devons dire Sonar« Où puis-je l'obtenir ? Ajoutons donc les lignes suivantes à son fichier de configuration. Mais il y a un point : les projets peuvent être multilingues, c'est-à-dire dans le dossier src il existe des codes sources pour plusieurs langages de programmation et une affiliation à l'un ou l'autre, et à son tour, l'utilisation de l'un ou l'autre plugin est déterminée par son extension. Et les informations de couverture peuvent être stockées à différents endroits pour différents langages de programmation, de sorte que chaque langage possède sa propre section pour sa configuration. Notre projet utilise Manuscrit, nous avons donc besoin d'une section de paramètres juste pour cela :

projet-sonar.propriétés:

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

Tout est prêt pour le premier lancement du scanner. Je tiens à souligner que le projet est SonarIl est créé automatiquement la première fois que vous exécutez le scanner pour un projet donné. Dans les temps ultérieurs, des informations seront accumulées afin de voir la dynamique des changements dans les paramètres du projet au fil du temps.

Utilisons donc la commande créée plus tôt dans package.json:

yarn run sonar 

Note: vous pouvez également utiliser le paramètre -X pour une journalisation plus détaillée.

Si le scanner a été lancé pour la première fois, le binaire du scanner lui-même sera téléchargé en premier. Après cela, il démarre et commence à analyser le serveur Sonar'a pour les plugins installés, calculant ainsi la langue prise en charge. Divers autres paramètres pour son fonctionnement sont également chargés : profils de qualité, règles actives, référentiel de métriques, règles du serveur.

Note: Nous ne nous y attarderons pas en détail dans le cadre de cet article, mais vous pouvez toujours contacter des sources officielles.

Ensuite, l'analyse du dossier commence src pour la disponibilité des fichiers sources pour toutes les langues prises en charge (si une langue spécifique n'est pas explicitement spécifiée), avec leur indexation ultérieure.

Viennent ensuite diverses autres analyses, sur lesquelles nous ne nous attarderons pas dans cet article (comme par exemple le peluchage, la détection de duplication de code, etc.).

A la toute fin du travail du scanner, toutes les informations collectées sont agrégées, archivées et envoyées au serveur.

Après cela, nous pouvons déjà voir ce qui s'est passé dans l'interface web :

Comme nous pouvons le voir, quelque chose a fonctionné et montre même une sorte de couverture, mais cela ne correspond pas à la nôtre. il y a-rapport.

Voyons cela. Examinons le projet plus en détail, cliquons sur la valeur de couverture et « passons » dans un rapport de fichier détaillé :

Ici, nous voyons, en plus du fichier principal examiné BonjourMonde.vue, il y a aussi un fichier main.ts, ce qui gâche toute l'image de la couverture. Mais comment se fait-il que nous l’ayons exclu du calcul de la couverture ? Oui, tout est correct, mais c'était au niveau il y a, mais le scanner l'a indexé, donc il s'est retrouvé dans ses calculs.

Réparons ceci :

projet-sonar.propriétés:

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

Je voudrais apporter une précision : en plus des dossiers qui sont spécifiés dans ce paramètre, tous les dossiers répertoriés dans le paramètre sont également ajoutés sonar.test.inclusions.

Après avoir lancé le scanner, nous voyons les informations correctes :

Regardons le point suivant - Profils de qualité. J'ai parlé plus haut du support Sonar'om plusieurs langues en même temps. C'est exactement ce que nous constatons. Mais nous savons que notre projet est écrit en TS, alors pourquoi surcharger le scanner avec des manipulations et des contrôles inutiles. Nous définirons la langue d'analyse en ajoutant un paramètre supplémentaire au fichier de configuration Sonar'UN:

projet-sonar.propriétés:

...
sonar.language=ts
...

Lançons à nouveau le scanner et voyons le résultat :

La couverture avait complètement disparu.

Si nous regardons le journal du scanner, nous pouvons voir la ligne suivante :

Autrement dit, nos fichiers de projet n'étaient tout simplement pas indexés.

La situation est la suivante : officiellement pris en charge VueJ est dans le plugin SonarJSqui est responsable de javascript.

Mais ce support n'est pas dans le plugin SonarTS pour TS, pour lequel un ticket officiel a été ouvert dans le bug tracker Sonar'UN:

1. https://jira.sonarsource.com/browse/MMF-1441
2. https://github.com/SonarSource/SonarJS/issues/1281

Voici quelques réponses d'un des représentants des développeurs de SonarQube, confirmant ce fait.

Mais tout a fonctionné pour nous, objectez-vous. Oui, essayons-le un peu "pirater".
S'il y a du soutien .vue-des dossiers Sonar'oh, alors essayons de lui dire de les considérer comme Manuscrit.

Ajoutons un paramètre :

projet-sonar.propriétés:

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

Lançons le scanner :

Et voilà, tout est revenu à la normale, et avec un seul profil pour Manuscrit. Autrement dit, nous avons réussi à résoudre le problème en support VueJs+TS pour SonarQube.

Essayons d'aller plus loin et d'améliorer un peu les informations de couverture.

Ce que nous avons fait jusqu'à présent :

• ajouté au projet Sonar-scanner;
• installation il y a pour générer des informations de couverture ;
• configuré Sonar-scanner;
• résolu le problème de support .vue-fichiers + Manuscrit.

En plus de la couverture des tests, il existe d'autres critères utiles et intéressants pour la qualité du code, par exemple la duplication du code et le nombre de lignes (impliquées dans le calcul des coefficients liés à la complexité du code) du projet.

Dans l'implémentation actuelle du plugin pour travailler avec TS (SonarTS) ne fonctionnera pas CPD (détecteur de copier-coller) et compter les lignes de code .vue-des dossiers.

Pour créer une situation synthétique de duplication de code, dupliquez simplement le fichier de composant sous un nom différent et ajoutez-le également au code. main.ts une fonction factice et dupliquez-la avec un nom différent. Pour vérifier la duplication comme dans .vueet .ts -des dossiers.

main.ts :

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

Pour ce faire, vous devez commenter temporairement la ligne de configuration :

projet-sonar.propriétés:

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

Redémarrons le scanner et testons :

yarn test && yarn run sonar

Bien sûr, notre couverture va diminuer, mais cela ne nous intéresse plus.

En termes de duplication de lignes de code, nous verrons :

Pour vérifier, nous utiliserons CPD-utilitaire - jscpd:

npx jscpd src

Pour les lignes de code :

Peut-être que cela sera résolu dans les futures versions du plugin SonarJS(TS). Je voudrais noter qu'ils commencent progressivement à fusionner ces deux plugins en un seul SonarJS, ce qui me semble correct.

Je voulais maintenant envisager la possibilité d'améliorer les informations de couverture.

Jusqu'à présent, nous pouvons voir la couverture des tests en termes de pourcentage pour l'ensemble du projet, et pour les fichiers en particulier. Mais il est possible d'élargir cet indicateur avec des informations sur la quantité unité-tests pour le projet, ainsi que dans le cadre de fichiers.

Il existe une bibliothèque qui peut il y a-convertir le rapport au format pour Sonar'UN:
données de test génériques - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Installons cette bibliothèque dans notre projet :

yarn add jest-sonar-reporter

Et ajoutez-le à la configuration il y a:

package.json :

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

Lançons maintenant le test :

yarn test

Après quoi un fichier sera créé à la racine du projet rapport-test.xml.

Utilisons-le dans la configuration Sonar'UN:

projet-sonar.propriétés:

…
sonar.testExecutionReportPaths=test-report.xml
…

Et redémarrez le scanner :

yarn run sonar

Voyons ce qui a changé dans l'interface Sonar'UN:

Et rien n'a changé. Le fait est que Sonar ne considère pas les fichiers décrits dans le rapport Jest comme des fichiers unité-des essais. Afin de corriger cette situation, nous utilisons le paramètre de configuration Sonar sonar.tests, dans lequel nous indiquerons explicitement les dossiers contenant des tests (nous n'en avons qu'un pour l'instant) :

projet-sonar.propriétés:

…
sonar.tests=src/components/__tests__
…

Redémarrons le scanner :

yarn run sonar

Voyons ce qui a changé dans l'interface :

Maintenant, nous avons vu le nombre de nos unité-tests et, après avoir échoué en cliquant à l'intérieur, nous pouvons voir la répartition de ce numéro parmi les fichiers du projet :

Conclusion

Nous avons donc examiné un outil d'analyse continue SonarQube. Nous y avons intégré avec succès un projet écrit en VueJs+TS. Correction de quelques problèmes de compatibilité. Nous avons augmenté le contenu informatif de l’indicateur de couverture des tests. Dans cet article, nous n'avons examiné qu'un seul des critères de qualité du code (peut-être l'un des principaux), mais SonarQube prend en charge d’autres critères de qualité, y compris les tests de sécurité. Mais toutes ces fonctionnalités ne sont pas entièrement disponibles dans Communautés-versions. L'une des fonctionnalités intéressantes et utiles est l'intégration SonarQube avec divers systèmes de gestion de référentiels de code, tels que GitLab et BitBucket. Pour prévenir demande de fusion pull (fusion)'a vers la branche principale du dépôt lorsque la couverture est dégradée. Mais c'est une histoire pour un article complètement différent.

PS: Tout ce qui est décrit dans l'article sous forme de code est disponible en ma fourchette.

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Utilisez-vous la plateforme SonarQube :

• 26,3%Oui5

• 15,8%Non3

• 15,8%J'ai entendu parler de cette plateforme et je souhaite l'utiliser3

• 10,5%J'ai entendu parler de cette plateforme et je ne veux pas l'utiliser2

• 0,0%J'utilise une autre plateforme0

• 31,6%C'est la première fois que j'entends parler d'elle6

19 utilisateurs ont voté. 3 utilisateurs se sont abstenus.

Source: habr.com