Sonarqube Cucumber Gherkin Analyzer
Descargo de responsabilidad
No quiero seguir manteniendo este complemento. Siéntase libre de hacerle ping si quieres hacerse cargo.
Descripción
Este complemento Sonarqube analiza archivos de características de pepino Gherkin y:
- Calcula las métricas: líneas de código, número de escenarios, etc.
- Verifica varias pautas para encontrar posibles errores y olores de código a través de más de 40 cheques
- Proporciona la capacidad de escribir sus propios cheques
Uso
- Descargar e instalar sonarqube
- Instale el complemento Gherkin de pepino mediante una descarga directa. La última versión es compatible con Sonarqube 6.7+.
- Instale su escáner favorito (Sonarqube Scanner, Maven, Ant, etc.)
- Analice su código
Aturdir
Es probable que sus archivos de características no se encuentren en los directorios de código fuente sino en los directorios de prueba. Por defecto, Sonarqube no analiza esos directorios de prueba. Por lo tanto, debe decirle explícitamente a Sonarqube que también analice los directorios de prueba que contienen sus archivos de características.
Digamos que la estructura de su proyecto es:
pom.xml
src
|-- main
|-- java
|-- resources
|-- test
|-- java
|-- resources
|-- features
|-- my-feature.feature
|-- my-other-feature.feature
En su archivo POM, necesitará agregar:
<properties>
<sonar.sources>pom.xml,src/main/java,src/main/resources,src/test/resources/features</sonar.sources>
</properties>
Cheques personalizados
¿Estás pensando en nuevas reglas valiosas? La versión 1.0 o mayor proporciona una API para escribir sus propios cheques personalizados. Aquí está disponible un complemento de muestra con explicaciones detalladas. Si sus reglas personalizadas pueden beneficiar a la comunidad, no dude en crear una solicitud de extracción para que la regla esté disponible en el analizador de pepino Gherkin.
¿Estás pensando en nuevas reglas que pueden beneficiar a la comunidad pero que no tienen el tiempo o las habilidades para escribirlas? Siéntase libre de crear un problema para que sus reglas se consideren en consideración.
Métrica
Declaraciones
Número de pasos.
Funciones
Número de escenarios y contornos de escenarios.
Clases
Número de características.
Reglas disponibles
- Las etiquetas "fixme" deben manejarse
- Las etiquetas "TODO" deben manejarse
- Todos los comentarios deben formatearse de manera consistente
- Y, pero pero los prefijos deben usarse en lugar de redundantes dados/cuando/luego prefijos
- La marca de pedido de bytes (BOM) no debe usarse para archivos UTF-8
- Se deben agregar pasos dados comunes al fondo
- Se deben eliminar los pasos duplicados
- Los caracteres de la línea final deben ser consistentes
- Ejemplos Las tablas de datos deben contener datos al menos dos filas de datos
- Las características deben escribirse en el mismo idioma
- Las características deben tener una descripción
- Las características deben tener un nombre
- Las características deben tener un nombre único
- Las características no deben contener demasiados escenarios
- Las características que no definen ningún escenario deben eliminarse
- Los nombres de los archivos deben cumplir con una convención de nomenclatura
- Los archivos deben contener una nueva línea vacía al final
- Los archivos que no definen ninguna función deben eliminarse
- Los pasos dados deben seguir una expresión regular
- Dado/cuando/luego los pasos deben definirse en el orden correcto
- Las líneas no deben terminar con espacios en blanco
- Se deben agregar columnas de la tabla de datos faltantes
- Los pasos no girados deben moverse fuera del fondo
- Solo se deben usar etiquetas de la lista blanca
- Expresión regular en comentarios
- Los escenarios deben definir al menos uno de cada uno de cada uno de los dos dados.
- Los escenarios deben tener un nombre
- Los escenarios deben tener un nombre único
- Los escenarios no deben contener demasiados pasos
- Los escenarios que no definen ningún paso deben eliminarse
- El código fuente debe estar correctamente sangrado
- Los errores de ortografía se deben corregir
- Los prefijos de pasos de estrella (*) no se deben usar
- Las oraciones pasadas no deberían ser demasiado largas
- No se deben usar pasos de tipo desconocido
- Los caracteres de tabulación no deben usarse
- Las etiquetas deben definirse en el nivel correcto
- Las etiquetas deben cumplir con una convención de nombres
- Las etiquetas no deben establecerse en ejemplos
- Entonces los pasos deben seguir una expresión regular
- Debe haber un sencillo cuando el paso por escenario
- Se deben eliminar las variables no utilizadas
- Se deben eliminar las etiquetas inútiles
- Cuando los pasos deben seguir una expresión regular
- La redacción debe permanecer a nivel comercial
