Utilizziamo attivamente la piattaforma nel nostro lavoro soundQube per mantenere la qualità del codice ad un livello elevato. Quando si integra uno dei progetti scritti in VueJs+Dattiloscritto, sono sorti problemi. Pertanto, vorrei raccontarvi più in dettaglio come siamo riusciti a risolverli.

In questo articolo parleremo, come ho scritto sopra, della piattaforma SonarQube. Una piccola teoria: di cosa si tratta in generale, per coloro che ne sentono parlare per la prima volta:

soundQube (ex Sonar) è una piattaforma open source per l'ispezione continua e la misurazione della qualità del codice.
Supporta l'analisi del codice e il rilevamento degli errori secondo le regole degli standard di programmazione MISRA C, MISRA C++, MITRE/CWE e CERT Secure Coding Standards. Può anche riconoscere gli errori dagli elenchi degli errori di programmazione OWASP Top 10 e CWE/SANS Top 25.
Nonostante la piattaforma utilizzi vari strumenti già pronti, SonarQube riduce i risultati in un'unica dashboard, mantenendo una cronologia delle esecuzioni e consentendo così di vedere l'andamento generale dei cambiamenti nella qualità del software durante lo sviluppo.

Maggiori dettagli possono essere trovati su il sito ufficiale

Sono supportati un gran numero di linguaggi di programmazione. A giudicare dalle informazioni dal collegamento sopra, si tratta di più di 25 lingue. Per supportare una lingua specifica, è necessario installare il plugin appropriato. La versione community include un plugin con cui lavorare Javascript (incluso il typeсript), anche se il wiki dice il contrario. Dietro Javascript risposte del plugin SonarJS, per Dattiloscritto SonarTS rispettivamente.

Il client ufficiale viene utilizzato per inviare informazioni sulla copertura scanner sonarqube, che, utilizzando le impostazioni da config-file, invia questi dati al server soundQube per un ulteriore consolidamento e aggregazione.

per Javascript c'è involucro npm. Quindi, iniziamo l'implementazione passo dopo passo soundQube в Vue-progetto utilizzando Dattiloscritto.

Per distribuire un server soundQube approfittiamone finestra mobile-composizione.

sonar.yaml:

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

Lanciare:

docker-compose -f sonar.yml up

Da allora in poi soundQube sarà disponibile presso: http://localhost:9001 .

Non ci sono ancora progetti e questo è giusto. Correggeremo questa situazione. Ho preso il progetto di esempio ufficiale per VueJS+TS+Jest. Pieghiamolo verso noi stessi:

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

Per prima cosa dobbiamo installare il client soundQubeche si chiama scanner sonarper npm c'è un involucro:

yarn add sonarqube-scanner

E aggiungi immediatamente il comando to script per lavorare con esso.

pacchetto.json:

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

Successivamente, affinché lo scanner funzioni, è necessario configurare le impostazioni del progetto in un file speciale. Cominciamo dalle basi.

sonar-project.properties:

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 - indirizzo Sonar'UN;
• sonar.projectKey – identificatore univoco del progetto sul server Sonar'UN;
• sonar.nomeprogetto – il suo nome, può essere modificato in qualsiasi momento, poiché il progetto è identificato da progettoKey;
• sorgenti.sonar – cartella con i sorgenti, solitamente questa src, ma può essere qualsiasi cosa. Questa cartella è impostata rispetto alla cartella principale, che è la cartella da cui viene avviato lo scanner;
• test.sonar – un parametro che va di pari passo con il precedente. Questa è la cartella in cui si trovano i test. In questo progetto non esiste una cartella di questo tipo e il test si trova accanto al componente da testare nella cartella 'test', quindi per ora lo ignoreremo e utilizzeremo il parametro successivo;
• inclusioni.test.sonar – percorso per i test tramite maschera, possono essere elencati più elementi separati da virgole;
• sonar.sourceEncoding – codifica per i file sorgente.

Per il primo avvio dello scanner tutto è pronto, tranne la principale azione precedente: avviare il motore di test stesso, in modo che possa generare informazioni sulla copertura, che lo scanner utilizzerà successivamente.

Ma per fare ciò, è necessario configurare il motore di test per generare queste informazioni. In questo progetto, il motore di test è Scherzare. E le sue impostazioni si trovano nella sezione corrispondente del file pacchetto.json.

Aggiungiamo queste impostazioni:

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

Cioè, impostiamo noi stessi il flag sulla necessità di calcolare la copertura e la fonte (insieme alle eccezioni) sulla base della quale verrà formata.

Ora eseguiamo il test:

yarn test

Vedremo quanto segue:

Il motivo è che non esiste alcun codice nel componente stesso. Risolviamo questo problema.

HelloWorld.vue:

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

Questo sarà sufficiente per calcolare la copertura.

Dopo aver riavviato il test, ci assicureremo di quanto segue:

Sullo schermo dovremmo vedere le informazioni sulla copertura e verrà creata una cartella nella cartella del progetto copertura con informazioni sulla copertura del test in un formato universale LCOV (estensione LTP GCOV).

Gcov è un'utilità distribuita gratuitamente per esaminare la copertura del codice. Gcov genera il numero esatto di esecuzioni per ciascuna istruzione in un programma e consente di aggiungere annotazioni al codice sorgente. Gcov viene fornito come utilità standard come parte del pacchetto GCC.
Leopoli - interfaccia grafica per gcov. Assembla file gcov per più file sorgente e produce una serie di pagine HTML con informazioni sul codice e sulla copertura. Vengono inoltre generate pagine per facilitare la navigazione. Lcov supporta la copertura di stringhe, funzioni e rami.

Una volta completati i test, le informazioni sulla copertura verranno visualizzate in copertura/lcov.info.
Dobbiamo dirlo Sonar'Dove posso prenderlo? Pertanto, aggiungiamo le seguenti righe al suo file di configurazione. Ma c'è un punto: i progetti possono essere multilingue, cioè nella cartella src esistono codici sorgente per diversi linguaggi di programmazione e affiliazione con l'uno o l'altro e, a sua volta, l'uso dell'uno o dell'altro plugin è determinato dalla sua estensione. Inoltre, le informazioni sulla copertura possono essere archiviate in luoghi diversi per diversi linguaggi di programmazione, quindi ogni lingua ha la propria sezione per configurarla. Il nostro progetto utilizza Dattiloscritto, quindi abbiamo bisogno di una sezione delle impostazioni appositamente per questo:

sonar-project.properties:

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

Tutto è pronto per il primo avvio dello scanner. Vorrei sottolineare che il progetto è SonarViene creato automaticamente la prima volta che si esegue lo scanner per un determinato progetto. Nei tempi successivi verranno accumulate informazioni in modo da poter vedere la dinamica dei cambiamenti dei parametri di progetto nel tempo.

Quindi, utilizziamo il comando creato in precedenza pacchetto.json:

yarn run sonar 

Nota: puoi anche usare il parametro -X per una registrazione più dettagliata.

Se lo scanner è stato avviato per la prima volta, verrà scaricato prima il file binario dello scanner stesso. Successivamente si avvia e avvia la scansione del server Sonar'a per i plugin installati, calcolando così la lingua supportata. Vengono caricati anche vari altri parametri per il suo funzionamento: profili di qualità, regole attive, repository di metriche, regole del server.

Nota: Non ci soffermeremo su di loro in dettaglio nell'ambito di questo articolo, ma puoi sempre contattare fonti ufficiali.

Successivamente, inizia l'analisi della cartella src per la disponibilità dei file sorgente per tutte le lingue supportate (se una specifica non è esplicitamente specificata), con la loro successiva indicizzazione.

Seguono poi diverse altre analisi, sulle quali non ci soffermeremo in questo articolo (ad esempio lint, rilevamento di duplicazioni di codice, ecc.).

Alla fine del lavoro dello scanner, tutte le informazioni raccolte vengono aggregate, archiviate e inviate al server.

Successivamente, possiamo già vedere cosa è successo nell'interfaccia web:

Come possiamo vedere, qualcosa ha funzionato e mostra anche una sorta di copertura, ma non corrisponde alla nostra Scherzare-rapporto.

Scopriamolo. Diamo un'occhiata al progetto più in dettaglio, clicchiamo sul valore di copertura e "cadiamo" in un rapporto dettagliato sul file:

Qui vediamo, oltre al file principale, esaminato HelloWorld.vue, c'è anche un file main.ts, che rovina l'intero quadro della copertura. Ma come mai lo abbiamo escluso dal calcolo della copertura? Sì, è tutto corretto, ma era al livello Scherzare, ma lo scanner lo ha indicizzato, quindi è finito nei suoi calcoli.

Risolviamo questo:

sonar-project.properties:

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

Vorrei fare una precisazione: oltre alle cartelle che vengono specificate in questo parametro vengono aggiunte anche tutte le cartelle elencate nel parametro inclusioni.test.sonar.

Dopo aver avviato lo scanner, vediamo le informazioni corrette:

Consideriamo il punto successivo: Profili di qualità. Ho parlato sopra del supporto Sonarsu più lingue contemporaneamente. Questo è esattamente ciò che stiamo vedendo. Ma sappiamo che il nostro progetto è scritto TS, quindi perché sforzare lo scanner con manipolazioni e controlli non necessari. Imposteremo la lingua per l'analisi aggiungendo un ulteriore parametro al file di configurazione Sonar'UN:

sonar-project.properties:

...
sonar.language=ts
...

Eseguiamo nuovamente lo scanner e vediamo il risultato:

La copertura era completamente scomparsa.

Se guardiamo il registro dello scanner, possiamo vedere la seguente riga:

Cioè, i nostri file di progetto semplicemente non sono stati indicizzati.

La situazione è la seguente: ufficialmente supportata VueJs è nel plugin SonarJS, di cui è responsabile Javascript.

Ma questo supporto non è nel plugin SonarTS per TS, per il quale è stato aperto un ticket ufficiale nel bug tracker Sonar'UN:

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

Ecco alcune risposte di uno dei rappresentanti degli sviluppatori SonarQube, che confermano questo fatto.

Ma per noi tutto ha funzionato, obietterai. Sì, lo è, proviamolo un po' “hackerare”.
Se c'è supporto .Visualizza-File Sonar'oh, allora proviamo a dirgli di considerarli come Dattiloscritto.

Aggiungiamo un parametro:

sonar-project.properties:

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

Avviamo lo scanner:

E, voilà, tutto è tornato alla normalità, e con un solo profilo per Dattiloscritto. Cioè, siamo riusciti a risolvere il problema in supporto VueJs+TS per soundQube.

Proviamo ad andare oltre e a migliorare un po' le informazioni sulla copertura.

Cosa abbiamo fatto finora:

• aggiunto al progetto Sonar-scanner;
• impostare Scherzare generare informazioni sulla copertura;
• configurato Sonar-scanner;
• risolto il problema dell'assistenza .Visualizza-file + Dattiloscritto.

Oltre alla copertura del test, ci sono altri interessanti criteri utili per la qualità del codice, ad esempio la duplicazione del codice e il numero di righe (coinvolte nel calcolo dei coefficienti legati alla complessità del codice) del progetto.

Nell'attuale implementazione del plugin con cui lavorare TS (SonarTS) non funzionerà CPD (rilevatore di copia e incolla) e contare le righe di codice .Visualizza-File.

Per creare una situazione sintetica di duplicazione del codice è sufficiente duplicare il file componente con un nome diverso e aggiungerlo anche lui al codice main.ts una funzione fittizia e duplicarla con un nome diverso. Per verificare la duplicazione come in .Visualizzae in ts -File.

principale.ts:

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

Per fare ciò, è necessario commentare temporaneamente la riga di configurazione:

sonar-project.properties:

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

Riavviamo lo scanner insieme ai test:

yarn test && yarn run sonar

Naturalmente la nostra copertura diminuirà, ma ora questo non ci interessa.

In termini di duplicazione di righe di codice, vedremo:

Per verificare useremo CPD-utilità - jscpd:

npx jscpd src

Per righe di codice:

Forse questo verrà risolto nelle future versioni del plugin SonarJS(TS). Vorrei sottolineare che stanno gradualmente iniziando a unire questi due plugin in uno solo SonarJS, cosa che ritengo corretta.

Ora volevo considerare la possibilità di migliorare le informazioni sulla copertura.

Finora possiamo vedere la copertura dei test in termini percentuali per l'intero progetto e per i file in particolare. Ma è possibile espandere questo indicatore con informazioni sulla quantità unità-test per il progetto, nonché nel contesto dei file.

C'è una biblioteca che può Scherzare-convertire il report in formato per Sonar'UN:
dati di test generici - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Installiamo questa libreria nel nostro progetto:

yarn add jest-sonar-reporter

E aggiungilo alla configurazione Scherzare:

pacchetto.json:

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

Ora eseguiamo il test:

yarn test

Dopodiché verrà creato un file nella radice del progetto rapporto-test.xml.

Usiamolo nella configurazione Sonar'UN:

sonar-project.properties:

…
sonar.testExecutionReportPaths=test-report.xml
…

E riavvia lo scanner:

yarn run sonar

Vediamo cosa è cambiato nell'interfaccia Sonar'UN:

E nulla è cambiato. Il fatto è che Sonar non considera file i file descritti nel rapporto Jest unità-test. Per correggere questa situazione, utilizziamo il parametro di configurazione Sonar test.sonar, in cui indicheremo esplicitamente le cartelle con i test (ne abbiamo solo una per ora):

sonar-project.properties:

…
sonar.tests=src/components/__tests__
…

Riavviamo lo scanner:

yarn run sonar

Vediamo cosa è cambiato nell'interfaccia:

Ora abbiamo visto il numero del nostro unità-tests e, avendo fallito cliccando all'interno, possiamo vedere la distribuzione di questo numero tra i file di progetto:

conclusione

Quindi, abbiamo esaminato uno strumento per l'analisi continua soundQube. Abbiamo integrato con successo in esso un progetto scritto in VueJs+TS. Risolti alcuni problemi di compatibilità. Abbiamo aumentato il contenuto informativo dell'indicatore di copertura del test. In questo articolo abbiamo esaminato solo uno dei criteri di qualità del codice (forse uno dei principali), ma soundQube supporta altri criteri di qualità, compresi i test di sicurezza. Ma non tutte queste funzionalità sono completamente disponibili in comunità-versioni. Una delle caratteristiche interessanti e utili è l'integrazione soundQube con vari sistemi di gestione del repository di codice, come GitLab e BitBucket. Impedire richiesta di unione pull(unione).'a al ramo principale del repository quando la copertura è ridotta. Ma questa è una storia per un articolo completamente diverso.

PS: Tutto quanto descritto nell'articolo sotto forma di codice è disponibile in la mia forchetta.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Utilizzi la piattaforma SonarQube:

• 26,3%Sì5

• 15,8%No3

• 15,8%Ho sentito parlare di questa piattaforma e voglio usarla3

• 10,5%Ho sentito parlare di questa piattaforma e non voglio usarla2

• 0,0%Sto utilizzando una piattaforma diversa0

• 31,6%La prima volta che ho sentito parlare di lei6

19 utenti hanno votato. 3 utenti si sono astenuti.

Fonte: habr.com