sonar gherkin plugin

Analyseur de concombre de sonarqube

Clause de non-responsabilité

Je ne veux pas continuer à maintenir ce plugin. N'hésitez pas à me faire cingler si vous voulez prendre le relais.

Description

Ce plugin Sonarqube analyse les fichiers de fonctionnalités de concombre Gherkin et:

• Calcul des métriques: lignes de code, nombre de scénarios, etc.
• Vérifie diverses directives pour trouver des bogues potentiels et des odeurs de code à travers plus de 40 chèques
• Offre la possibilité d'écrire vos propres chèques

Usage

1. Télécharger et installer Sonarqube
2. Installez le plugin Gherkin du concombre par téléchargement direct. La dernière version est compatible avec Sonarqube 6.7+.
3. Installez votre scanner préféré (scanner Sonarqube, maven, fourmi, etc.)
4. Analysez votre code

Maven

Il est probable que vos fichiers de fonctionnalités ne soient pas situés dans les répertoires de code source mais dans les répertoires de test. Par défaut, Sonarqube n'analyse pas ces répertoires de test. Ainsi, vous devez dire explicitement à Sonarqube d'analyser également les répertoires de test contenant vos fichiers de fonctionnalité.

Disons que la structure de votre projet est:

 pom.xml
src
  |-- main
        |-- java
        |-- resources
  |-- test
        |-- java
        |-- resources
              |-- features
                    |-- my-feature.feature
                    |-- my-other-feature.feature
                                   
                

Dans votre fichier POM, vous devrez ajouter:

 <properties>
  <sonar.sources>pom.xml,src/main/java,src/main/resources,src/test/resources/features</sonar.sources>
</properties>  

Chèques personnalisés

Vous pensez à de nouvelles règles précieuses? La version 1.0 ou plus fournit une API pour rédiger vos propres chèques personnalisées. Un exemple de plugin avec des explications détaillées est disponible ici. Si vos règles personnalisées peuvent bénéficier à la communauté, n'hésitez pas à créer une demande de traction afin de rendre la règle disponible dans l'analyseur de concombre Gherkin.

Vous pensez à de nouvelles règles qui peuvent bénéficier à la communauté mais qui n'ont pas le temps ou les compétences pour les écrire? N'hésitez pas à créer un problème pour que vos règles soient prises en considération.

Métrique

Affirmations

Nombre d'étapes.

Fonctions

Nombre de scénarios et de contours de scénarios.

Classes

Nombre de fonctionnalités.

Règles disponibles

• Les balises "FixMe" doivent être gérées
• Les balises "TODO" doivent être gérées
• Tous les commentaires doivent être formatés de manière cohérente
• Et et mais les préfixes doivent être utilisés au lieu de redondant donné / quand / puis préfixes
• La marque de commande des octets (BOM) ne doit pas être utilisée pour les fichiers UTF-8
• Des étapes données courantes doivent être ajoutées à l'arrière-plan
• Les étapes dupliquées doivent être supprimées
• Les caractères de ligne finale doivent être cohérents
• Exemples Les tableaux de données doivent contenir des données au moins deux lignes de données
• Les fonctionnalités doivent être écrites dans la même langue
• Les fonctionnalités doivent avoir une description
• Les fonctionnalités doivent avoir un nom
• Les fonctionnalités devraient avoir un nom unique
• Les fonctionnalités ne doivent pas contenir trop de scénarios
• Les fonctionnalités qui ne définissent aucun scénario doivent être supprimées
• Les noms de fichiers doivent se conformer à une convention de dénomination
• Les fichiers doivent contenir une nouvelle ligne vide à la fin
• Les fichiers qui ne définissent aucune fonctionnalité doivent être supprimés
• Les étapes étant donné doivent suivre une expression régulière
• Les étapes données / quand / alors doivent être définies dans le bon ordre
• Les lignes ne doivent pas se terminer avec des espaces de fin
• Des colonnes de table de données manquantes doivent être ajoutées
• Les étapes non données doivent être déplacées hors de l'arrière-plan
• Seules les balises de la liste blanche doivent être utilisées
• Expression régulière sur le commentaire
• Les scénarios doivent définir au moins un de chaque type de pas donné / quand / puis
• Les scénarios devraient avoir un nom
• Les scénarios devraient avoir un nom unique
• Les scénarios ne doivent pas contenir trop d'étapes
• Les scénarios qui ne définissent aucune étape doivent être supprimés
• Le code source doit être correctement en retrait
• Les erreurs d'orthographe doivent être corrigées
• Les préfixes étoiles (*) ne doivent pas être utilisés
• Les phrases à pas ne devraient pas être trop longues
• Les étapes du type inconnu ne doivent pas être utilisées
• Les caractères de tabulation ne doivent pas être utilisés
• Les balises doivent être définies au bon niveau
• Les balises doivent se conformer à une convention de dénomination
• Les balises ne doivent pas être définies sur des exemples
• Alors les étapes doivent suivre une expression régulière
• Il devrait y en avoir un seul lorsque le scénario
• Les variables inutilisées doivent être supprimées
• Les balises inutiles doivent être supprimées
• Lorsque les étapes doivent suivre une expression régulière
• Le libellé doit rester au niveau de l'entreprise