Analisador de pepino sonarqube
Isenção de responsabilidade
Não quero continuar mantendo este plug -in. Sinta -se à vontade para me pingar se quiser assumir o controle.
Descrição
Este plug -in Sonarqube analisa os arquivos de recursos do pepino e:
- Calcula métricas: linhas de código, número de cenários, etc.
- Verifica várias diretrizes para descobrir possíveis bugs e o código cheira com mais de 40 cheques
- Fornece a capacidade de escrever seus próprios cheques
Uso
- Baixar e instalar Sonarqube
- Instale o plug -in Gherkin do pepino por um download direto. A versão mais recente é compatível com o Sonarqube 6.7+.
- Instale seu scanner favorito (Sonarqube Scanner, Maven, Ant, etc.)
- Analise seu código
Maven
É provável que seus arquivos de recursos não estejam localizados nos diretórios de código -fonte, mas nos diretórios de teste. Por padrão, o Sonarqube não analisa esses diretórios de teste. Assim, você deve dizer explicitamente ao Sonarqube para analisar os diretórios de teste que contêm seus arquivos de recursos.
Digamos que a estrutura do seu projeto é:
pom.xml
src
|-- main
|-- java
|-- resources
|-- test
|-- java
|-- resources
|-- features
|-- my-feature.feature
|-- my-other-feature.feature
Em seu arquivo POM, você precisaria adicionar:
<properties>
<sonar.sources>pom.xml,src/main/java,src/main/resources,src/test/resources/features</sonar.sources>
</properties>
Verificações personalizadas
Você está pensando em novas regras valiosas? A versão 1.0 ou superior fornece uma API para escrever suas próprias verificações personalizadas. Um plug -in de amostra com explicações detalhadas está disponível aqui. Se suas regras personalizadas podem beneficiar a comunidade, sinta -se à vontade para criar uma solicitação de tração para disponibilizar a regra no analisador Gherkin.
Você está pensando em novas regras que podem beneficiar a comunidade, mas não têm tempo ou habilidades para escrevê -las? Sinta -se à vontade para criar um problema para que suas regras sejam levadas em consideração.
Métricas
Declarações
Número de etapas.
Funções
Número de cenários e cenários esboços.
Classes
Número de recursos.
Regras disponíveis
- As tags "Fixme" devem ser tratadas
- Tags "TODO" devem ser tratadas
- Todos os comentários devem ser formatados de forma consistente
- E e mas os prefixos devem ser usados em vez de redundantes dados/quando/depois prefixos
- Marca de pedidos de byte (BOM) não deve ser usada para arquivos UTF-8
- As etapas comuns dadas devem ser adicionadas ao fundo
- Etapas duplicadas devem ser removidas
- Os caracteres finais devem ser consistentes
- Exemplos Tabelas de dados devem conter dados pelo menos duas linhas de dados
- Os recursos devem ser escritos no mesmo idioma
- Os recursos devem ter uma descrição
- Os recursos devem ter um nome
- Os recursos devem ter um nome único
- Os recursos não devem conter muitos cenários
- Recursos que não definem nenhum cenário devem ser removidos
- Nomes de arquivos devem cumprir uma convenção de nomenclatura
- Os arquivos devem conter uma nova linha vazia no final
- Arquivos que não definem nenhum recurso devem ser removidos
- Dadas as etapas devem seguir uma expressão regular
- Dado/quando/então as etapas devem ser definidas na ordem certa
- As linhas não devem terminar com os espaços em branco à direita
- As colunas de tabela de dados ausentes devem ser adicionadas
- Etapas não dadas devem ser retiradas do fundo
- Somente tags da lista de permissões devem ser usadas
- Expressão regular no comentário
- Os cenários devem definir pelo menos um de cada tipo de dado/quando/depois tipo de etapa
- Cenários devem ter um nome
- Cenários devem ter um nome único
- Os cenários não devem conter muitos passos
- Cenários que não definem nenhuma etapa devem ser removidos
- O código -fonte deve ser corretamente recuado
- Erros de ortografia devem ser consertados
- Star (*) prefixos de etapas não devem ser usados
- As frases de passo não devem demorar muito
- Etapas do tipo desconhecido não devem ser usadas
- Os caracteres de tabulação não devem ser usados
- Tags devem ser definidas no nível certo
- Tags devem cumprir uma convenção de nomenclatura
- Tags não devem ser definidas em exemplos
- Então as etapas devem seguir uma expressão regular
- Deve haver um único etapa por cenário
- Variáveis não utilizadas devem ser removidas
- Tags inúteis devem ser removidas
- Quando as etapas devem seguir uma expressão regular
- A redação deve permanecer no nível dos negócios
