Em nosso trabalho, usamos ativamente a plataforma SonarQube para manter a qualidade do código em um nível alto. Ao integrar um dos projetos escritos em VueJs+Typescript, surgiram problemas. Portanto, gostaria de contar em detalhes como conseguimos resolvê-los.

Neste artigo, falaremos, como mencionei antes, sobre a plataforma SonarQube. Um pouco de teoria — o que é isso exatamente, para aqueles que a ouvem pela primeira vez:

SonarQube (anteriormente Sonar) — é uma plataforma de código aberto para análise contínua (em inglês, continuous inspection) e medição da qualidade do código.
Suporta a análise de código e a busca por erros segundo as regras dos padrões de programação MISRA C, MISRA C++, MITRE/CWE e CERT Secure Coding Standards. Também é capaz de reconhecer erros das listas OWASP Top-10 e CWE/SANS Top-25 erros de programação.
Embora a plataforma utilize várias ferramentas prontas, o SonarQube unifica os resultados em um único painel de informações (em inglês, dashboard), mantendo o histórico de execuções e permitindo, assim, visualizar a tendência geral de mudança na qualidade do software durante o desenvolvimento.

Você pode saber mais em site oficial

Um grande número de linguagens de programação é suportado. Segundo as informações do link acima — são mais de 25 linguagens. Para suportar uma linguagem específica, é necessário instalar o plugin correspondente. A versão community inclui o plugin para trabalhar com Javascript (incluindo typesсript), embora na wiki esteja escrito o contrário. O responsável por isso é o plugin Javascript SonarJS , para TypescriptSonarTS Para enviar informações sobre a cobertura, é utilizado o cliente oficial respectivamente.

sonarqube-scanner , que, utilizando as configurações do-arquivo, envia esses dados para o servidor configpara posterior consolidação e agregação. SonarQube npm-wrapper.

Para Javascript tem Então, vamos começar a implementação passo a passodo projeto Vue SonarQube em -projeto, utilizandoTypescript Para implementar o servidor.

vamos usar SonarQube sonar.yaml docker-compose.

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

docker-compose -f sonar.yml up

Início:

Após isso,

estará disponível no endereço – SonarQube Por enquanto, não há projetos nele e isso é justo. Vamos corrigir essa situação. Como base, peguei um projeto de exemplo oficial para http://localhost:9001 .

VueJS+TS+Jest . Vamos cloná-lo para o nosso ambiente:git clone https://github.com/vuejs/vue-test-utils-typescript-example.git

Primeiro, precisamos instalar o cliente

, que se chama SonarQubesonar-scanner existe um wrapper:, para npm yarn add sonarqube-scanner

E logo iremos adicionar um comando no

para trabalharmos com ele. scripts package.json:

package.json:

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

Em seguida, para o funcionamento do scanner, é necessário definir as configurações do projeto em um arquivo específico. Vamos começar com o básico.

sonar-project.properties:

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

sonar.projectKey=teste-projeto-vuejs-ts
sonar.projectName=Aplicação de Teste (VueJS+TS)

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

sonar.host.url – endereço Sonar's;
sonar.projectKey – identificador único do projeto no servidor Sonar's;
sonar.projectName – seu nome, que pode ser alterado a qualquer momento, pois a identificação do projeto é feita pelo projectKey;
sonar.sources – pasta com os códigos-fonte, geralmente é src, mas pode ser qualquer um. Esta pasta é definida em relação à pasta raiz, que é a pasta de onde o scanner foi iniciado;
sonar.tests – parâmetro que vem em par com o anterior. Esta é a pasta onde estão os testes. Neste projeto, não existe tal pasta, e o teste está ao lado do componente a ser testado na pasta 'test', portanto, vamos ignorá-lo por enquanto e usar o próximo parâmetro;
sonar.test.inclusions – caminho para os testes usando máscara, podendo haver vários elementos listados por vírgula;
sonar.sourceEncoding – codificação para os arquivos fonte.

Para a primeira execução do scanner, tudo está pronto, exceto uma ação preliminar: iniciar o motor de testes para gerar informações sobre a cobertura que o scanner utilizará posteriormente.

Mas para isso, é necessário configurar o motor de testes para gerar essas informações. Neste projeto, o motor de testes é Jest. E suas configurações estão na seção correspondente do arquivo package.json.

Vamos adicionar essas configurações:

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

Ou seja, estamos definindo a flag para calcular a cobertura e a fonte (junto com as exclusões) a partir da qual ela será gerada.

Agora vamos executar o teste:

yarn test

Veremos o seguinte:

A razão é que o próprio componente, na verdade, não possui código. Vamos corrigir isso.

HelloWorld.vue:

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

Isso será suficiente para calcular a cobertura.

Após reiniciar o teste, vamos confirmar isso:

Na tela, devemos ver informações sobre a cobertura, e na pasta do projeto, será criada uma pasta coverage com informações sobre a cobertura dos testes em um formato universal LCOV (extensão LTP GCOV).

Gcov — uma ferramenta de código aberto para análise de cobertura de código. O Gcov gera uma contagem precisa de execuções para cada instrução no programa e permite adicionar anotações ao código-fonte. O Gcov é fornecido como uma ferramenta padrão no pacote GCC.
Lcov — uma interface gráfica para o gcov. Ele coleta arquivos gcov para vários arquivos de código-fonte e cria um conjunto de páginas HTML com código e informações de cobertura. Também são geradas páginas para facilitar a navegação. O Lcov suporta cobertura de linhas, funções e bifurcações.

Após a execução dos testes, as informações de cobertura estarão disponíveis em coverage/lcov.info.
Precisamos informar Sonarde onde obtê-la. Portanto, adicionaremos as seguintes linhas ao seu arquivo de configuração. Mas há um detalhe: os projetos podem ser multilíngues, ou seja, na pasta src estão os códigos-fonte para várias linguagens de programação e a afiliação a uma ou outra, e, por sua vez, o uso de determinado plugin é determinado pela sua extensão. E as informações de cobertura podem ser armazenadas em locais diferentes para diferentes linguagens de programação, portanto, para cada LPP há sua seção de configuração específica. Nosso projeto usa Para implementar o servidor, portanto, precisamos da seção de configurações precisamente para ele:

sonar-project.properties:

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

Está tudo pronto para a primeira execução do scanner. Quero notar que o projeto em Sonaré criado automaticamente na primeira execução do scanner para este projeto. Nas execuções subsequentes, as informações já serão acumuladas para ver a dinâmica das mudanças nos parâmetros do projeto ao longo do tempo.

Então, vamos usar o comando criado anteriormente em package.json:

yarn run sonar

Nota: também é possível usar o parâmetro -X para um registro mais detalhado.

Se esta é a primeira execução do scanner, inicialmente o binário do próprio scanner será baixado. Após isso, ele será executado e começará a escanear o servidor Sonarpara verificar os plugins instalados, calculando assim as LPP suportadas. Além disso, outros diversos parâmetros para o seu funcionamento são carregados: quality profiles, active rules, metrics repository, server rules.

Nota: não entraremos em detalhes sobre eles neste artigo, mas você sempre pode consultar fontes oficiais.

Em seguida, o análise da pasta começa src em relação à presença de arquivos-fonte para todas as linguagens de programação suportadas (a menos que uma específica tenha sido claramente especificada), com posterior indexação.

A seguir, temos diversas outras análises que não detalharemos neste artigo (por exemplo, como: linting, detecção de duplicação de código, etc.).

No final da execução do scanner, ocorre a agregação de todas as informações coletadas, a arquivação e o envio para o servidor.

Depois disso, já podemos ver o que foi gerado na interface web:

Como podemos ver, algo foi gerado, e até mostra alguma cobertura, mas isso não corresponde ao nosso Jest-relatório.

Vamos investigar. Vamos olhar o projeto com mais detalhes, clicar no valor de cobertura e "mergulhar" no relatório detalhado por arquivos:

Aqui vemos que, além do arquivo principal que estamos analisando, HelloWorld.vue, também está presente o arquivo main.ts, que está comprometendo toda a análise de cobertura. Mas como pode ser, já que o excluímos do cálculo de cobertura? Sim, está correto, mas isso aconteceu no nível Jest, mas o scanner o indexou, por isso ele foi incluído em seus cálculos.

Vamos corrigir isso:

sonar-project.properties:

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

Gostaria de esclarecer: além das pastas especificadas neste parâmetro, todas as pastas listadas no parâmetro também são adicionadas. sonar.test.inclusions.

Após a execução do scanner, já vemos informações corretas:

Vamos analisar o próximo ponto - Perfis de Qualidade. Como mencionei acima, há suporte a várias linguagens de programação simultaneamente. É exatamente isso que estamos observando. Mas sabemos que nosso projeto foi escrito em Sonar, então por que sobrecarregar o scanner com manipulações e verificações desnecessárias? Vamos definir a linguagem para a análise através da adição de mais um parâmetro no arquivo de configuração TS: Sonar... sonar.language=ts ...

sonar-project.properties:

Vamos reiniciar o scanner e observar o resultado:

A cobertura desapareceu completamente.

Se olharmos no log do scanner, podemos ver a seguinte linha:

Ou seja, os arquivos do nosso projeto simplesmente não foram indexados.

A situação é a seguinte: oficialmente, o suporte a

VueJs está presente no plugin , que é responsável por , para TypescriptMas esse suporte não está no plugin Javascript.

, sobre o qual foi criado um ticket oficial no tracker de bugs. Para enviar informações sobre a cobertura, é utilizado o cliente oficial para TSAqui estão algumas respostas de um dos representantes dos desenvolvedores do SonarQube, confirmando esse fato. Sonar... sonar.language=ts ...

Mas tudo funcionava, você pode argumentar. Sim, foi assim. Vamos tentar um pouco

“hackear” Se há suporte a.
.vue -arquivos- arquivos SonarEntão, vamos tentar dizer a ele para considerar como Para implementar o servidor.

Vamos adicionar o parâmetro:

sonar-project.properties:

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

Vamos rodar o scanner:

E, voilà, tudo voltou ao normal, com um perfil apenas para Para implementar o servidor. Ou seja, conseguimos resolver o problema de suporte VueJs+TS para SonarQube.

Vamos nos aprofundar um pouco mais e melhorar as informações sobre a cobertura.

O que fizemos até agora:

Adicionamos ao projeto Sonar-o scanner;
Configuramos Jest para gerar informações sobre a cobertura;
Configuramos Sonar-o scanner;
resolvemos o problema de suporte -arquivos-arquivos + Para implementar o servidor.

Além da cobertura dos testes, existem outros critérios de qualidade de código interessantes e úteis, como a duplicação de código e a contagem de linhas (que participa do cálculo dos coeficientes relacionados à complexidade do) projeto.

Na implementação atual do plugin para trabalhar com TS (Para enviar informações sobre a cobertura, é utilizado o cliente oficial) não funcionará CPD (Copy Paste Detector) e contagem de linhas de código -arquivos-arquivos.

Para criar uma situação sintética de duplicação de código, basta duplicar o arquivo do componente com um nome diferente, e também adicionar no código main.ts uma função vazia e duplicá-la com um nome diferente. Para verificar a duplicação, como em -arquivos, quanto em .ts -arquivos.

main.ts:

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

Para isso, é necessário comentar temporariamente a linha de configuração:

sonar-project.properties:

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

Vamos reiniciar o scanner junto com os testes:

yarn test && yarn run sonar

Com certeza nossa cobertura cairá, mas isso não nos interessa agora.

Na perspectiva da duplicação de linhas de código, veremos:

Para verificar, usaremos CPD-a ferramenta – jscpd:

npx jscpd src

Para linhas de código:

Isso pode ser resolvido em versões futuras dos plugins SonarJS(TS). Gostaria de ressaltar que eles estão gradualmente começando a unir esses dois plugins em um só , para Typescript, o que, na minha opinião, é correto.

Agora, gostaria de considerar a opção de melhorar as informações sobre a cobertura.

Atualmente, vemos a cobertura dos testes em percentual, em todo o projeto, e por arquivos especificamente. Mas há como ampliar esse indicador com informações sobre a quantidade um arquivo-de testes no projeto, bem como na perspectiva dos arquivos.

Existe uma biblioteca que pode Jest-converter o relatório para o formato de Sonar... sonar.language=ts ...
generic test data — https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Vamos instalar essa biblioteca no nosso projeto:

yarn add jest-sonar-reporter

E vamos adicioná-la à configuração Jest:

package.json:

...
"testResultsProcessor": "jest-sonar-reporter"
...

Agora vamos executar o teste:

yarn test

Após isso, será criado um arquivo test-report.xml.

Vamos utilizá-lo na configuração Sonar... sonar.language=ts ...

sonar-project.properties:

...
sonar.testExecutionReportPaths=test-report.xml
...

E reiniciaremos o scanner:

yarn run sonar

Vamos ver o que mudou na interface Sonar... sonar.language=ts ...

E nada mudou. O fato é que o Sonar não considera os arquivos descritos no relatório do Jest como arquivos um arquivo-de testes. Para corrigir essa situação, usaremos um parâmetro de configuração Sonar sonar.tests, onde indicaremos claramente as pastas com os testes (por enquanto só temos uma):

sonar-project.properties:

…
sonar.tests=src/components/__tests__
…

Vamos reiniciar o scanner:

yarn run sonar

Vamos ver o que mudou na interface:

Agora podemos ver a quantidade dos nossos um arquivo-testes e, ao clicar, podemos observar a distribuição desse número pelos arquivos do projeto:

Conclusão

Assim, examinamos a ferramenta para análise contínua SonarQube. Integramos com sucesso o projeto escrito em VueJs+TS. Resolvemos alguns problemas de compatibilidade. Aumentamos a informatividade do indicador de cobertura de testes. Neste artigo, discutimos apenas um dos critérios de qualidade de código (possivelmente um dos principais), mas SonarQube suporta outros critérios de qualidade, incluindo testes de segurança. Contudo, nem todas essas funcionalidades estão totalmente disponíveis na versão community. Uma das possibilidades interessantes e úteis são as integrações SonarQube com diferentes sistemas de controle de versão de código, como GitLab e BitBucket. Para evitar merge pull(merge) requestna ramificação principal do repositório com degradação de cobertura. Mas isso é uma história de um artigo completamente diferente.

PS: Tudo o que foi descrito no artigo em formato de código está disponível em meu fork.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.