Utilizăm în mod activ platforma în munca noastră soundQube pentru a menține calitatea codului la un nivel ridicat. La integrarea unuia dintre proiectele scrise în VueJs+Typescript, au apărut probleme. Prin urmare, aș dori să vă spun mai detaliat cum am reușit să le rezolvăm.

În acest articol vom vorbi, așa cum am scris mai sus, despre platforma SonarQube. O mică teorie - ce este în general, pentru cei care aud despre ea pentru prima dată:

soundQube (fost Sonar) este o platformă open source pentru inspecție continuă și măsurare a calității codului.
Suportă analiza codului și detectarea erorilor conform regulilor standardelor de programare MISRA C, MISRA C++, MITRE/CWE și CERT Secure Coding Standards. De asemenea, poate recunoaște erorile din listele de erori de programare OWASP Top 10 și CWE/SANS Top 25.
În ciuda faptului că platforma folosește diverse instrumente gata făcute, SonarQube reduce rezultatele la un singur tablou de bord, păstrând un istoric al rulărilor și, astfel, permițându-vă să vedeți tendința generală a schimbărilor în calitatea software-ului în timpul dezvoltării.

Mai multe detalii pot fi găsite la site-ul oficial

Sunt acceptate un număr mare de limbaje de programare. Judecând după informațiile din linkul de mai sus, acestea sunt mai mult de 25 de limbi. Pentru a accepta o anumită limbă, trebuie să instalați pluginul corespunzător. Versiunea comunității include un plugin pentru a lucra cu Javascript (inclusiv tipscript), deși wiki spune contrariul. In spate Javascript răspunsuri plugin SonarJS, pentru Typescript SonarTS respectiv.

Clientul oficial este folosit pentru a trimite informații de acoperire sonarqube-scaner, care, folosind setările de la config-file, trimite aceste date către server soundQube pentru consolidare și agregare ulterioară.

Pentru Javascript există ambalaj npm. Deci, să începem implementarea pas cu pas soundQube в Vue-folosirea proiectului manuscris dactilografiat.

Pentru a implementa un server soundQube hai sa profitam Docker-scriere.

sonar.yaml:

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

Lansa:

docker-compose -f sonar.yml up

Ulterior, soundQube va fi disponibil la: http://localhost:9001 .

Nu există încă proiecte în el și este corect. Vom corecta această situație. Am luat exemplul oficial de proiect pentru VueJS+TS+Jest. Să o înclinăm spre noi înșine:

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

Mai întâi trebuie să instalăm clientul soundQube, Care e numit sonar-scanerpentru NPM există un înveliș:

yarn add sonarqube-scanner

Și adăugați imediat comanda la script-uri a lucra cu el.

package.json:

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

Apoi, pentru ca scanerul să funcționeze, trebuie să setați setările proiectului într-un fișier special. Să începem cu elementele de bază.

sonar-proiect.proprietati:

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 - abordare Sonar'A;
sonar.projectKey – identificatorul unic de proiect pe server Sonar'A;
sonar.projectName – numele acestuia, poate fi schimbat oricând, deoarece proiectul este identificat prin projectKey;
sonar.surse – folder cu surse, de obicei aceasta src, dar poate fi orice. Acest folder este setat relativ la folderul rădăcină, care este folderul din care este lansat scanerul;
sonar.teste – un parametru care merge în tandem cu cel anterior. Acesta este folderul în care se află testele. În acest proiect, nu există un astfel de folder, iar testul se află lângă componenta testată în folderul 'test', așa că îl vom ignora pentru moment și vom folosi următorul parametru;
sonar.test.incluziuni – cale pentru teste folosind o mască, pot exista mai multe elemente enumerate separate prin virgule;
sonar.sourceEncoding – codificare pentru fișierele sursă.

Pentru prima lansare a scanerului, totul este gata, cu excepția acțiunii principale precedente: lansarea în sine a motorului de testare, astfel încât acesta să poată genera informații despre acoperire, pe care scanerul le va folosi ulterior.

Dar pentru a face acest lucru, trebuie să configurați motorul de testare pentru a genera aceste informații. În acest proiect, motorul de testare este există. Și setările sale sunt în secțiunea corespunzătoare a fișierului pachet.json.

Să adăugăm aceste setări:

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

Adică, setăm steagul în sine pentru necesitatea de a calcula acoperirea și sursa (împreună cu excepții) pe baza căreia se va forma.

Acum să rulăm testul:

yarn test

Vom vedea următoarele:

Motivul este că nu există cod în componenta în sine. Să reparăm asta.

HelloWorld.vue:

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

Acest lucru va fi suficient pentru a calcula acoperirea.

După repornirea testului, ne vom asigura că:

Pe ecran ar trebui să vedem informații despre acoperire, iar un folder va fi creat în folderul proiectului acoperire cu informații despre acoperirea testului într-un format universal LCOV (extensie LTP GCOV).

Gcov este un utilitar distribuit gratuit pentru examinarea acoperirii codului. Gcov generează numărul exact de execuții pentru fiecare instrucțiune dintr-un program și vă permite să adăugați adnotări la codul sursă. Gcov vine ca un utilitar standard ca parte a pachetului GCC.
Lcov - interfata grafica pentru gcov. Asamblează fișiere gcov pentru mai multe fișiere sursă și produce un set de pagini HTML cu informații despre cod și acoperire. De asemenea, paginile sunt generate pentru a facilita navigarea. Lcov acceptă acoperirea șirurilor, funcțiilor și ramurilor.

După finalizarea testelor, informațiile de acoperire vor fi găsite în coverage/lcov.info.
Trebuie să spunem Sonar'De unde pot să-l iau? Prin urmare, să adăugăm următoarele linii la fișierul său de configurare. Dar există un punct: proiectele pot fi multilingve, adică în folder src există coduri sursă pentru mai multe limbaje de programare și afilierea cu unul sau altul și, la rândul său, utilizarea unuia sau altui plugin este determinată de extensia acestuia. Și informațiile de acoperire pot fi stocate în locuri diferite pentru diferite limbaje de programare, astfel încât fiecare limbă are propria sa secțiune pentru configurarea acestui lucru. Proiectul nostru folosește manuscris dactilografiat, așa că avem nevoie de o secțiune de setări doar pentru asta:

sonar-proiect.proprietati:

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

Totul este gata pentru prima lansare a scanerului. Aș dori să menționez că proiectul este Sonar'e este creat automat prima dată când rulați scanerul pentru un proiect dat. În perioadele ulterioare, informațiile vor fi acumulate pentru a vedea dinamica modificărilor parametrilor proiectului în timp.

Deci, să folosim comanda creată mai devreme în pachet.json:

yarn run sonar

Nota: poti folosi si parametrul -X pentru o înregistrare mai detaliată.

Dacă scanerul a fost lansat pentru prima dată, atunci binarul scanerului în sine va fi descărcat mai întâi. După aceea pornește și începe scanarea serverului Sonar'a pentru pluginurile instalate, calculând astfel limba acceptată. De asemenea, sunt încărcați diferiți alți parametri pentru funcționarea acestuia: profiluri de calitate, reguli active, depozit de metrici, reguli de server.

Nota: Nu ne vom opri asupra lor în detaliu în cadrul acestui articol, dar puteți contacta oricând surse oficiale.

În continuare, începe analiza folderului src pentru disponibilitatea fișierelor sursă pentru toate (dacă unul anume nu este specificat în mod explicit) suportat, cu indexarea lor ulterioară.

Urmează diverse alte analize, asupra cărora nu ne concentrăm în acest articol (de exemplu, cum ar fi scame, detectarea dublării codului etc.).

La sfârșitul lucrării scanerului, toate informațiile colectate sunt agregate, arhivate și trimise la server.

După aceasta, putem vedea deja ce s-a întâmplat în interfața web:

După cum putem vedea, ceva a funcționat și chiar arată un fel de acoperire, dar nu se potrivește cu a noastră există-raport.

Să ne dăm seama. Să ne uităm la proiect mai detaliat, să facem clic pe valoarea de acoperire și să „căpăm” într-un raport detaliat al fișierului:

Aici vedem, pe lângă dosarul principal, examinat HelloWorld.vue, există și un dosar principale.ts, care strică întreaga imagine a acoperirii. Dar cum de l-am exclus din calculul acoperirii. Da, totul este corect, dar a fost la nivel există, dar scanerul l-a indexat, așa că a ajuns în calculele sale.

Să reparăm asta:

sonar-proiect.proprietati:

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

Aș dori să fac o precizare: pe lângă folderele care sunt specificate în acest parametru, sunt adăugate și toate folderele enumerate în parametru sonar.test.incluziuni.

După lansarea scanerului, vedem informațiile corecte:

Să ne uităm la următorul punct - Profiluri de calitate. Am vorbit mai sus despre suport Sonardin mai multe limbi în același timp. Este exact ceea ce vedem. Dar știm că proiectul nostru este scris TS, deci de ce să încordați scanerul cu manipulări și verificări inutile. Vom seta limba pentru analiză adăugând încă un parametru la fișierul de configurare Sonar'A:

sonar-proiect.proprietati:

...
sonar.language=ts
...

Să rulăm din nou scanerul și să vedem rezultatul:

Acoperirea a dispărut complet.

Dacă ne uităm la jurnalul scanerului, putem vedea următoarea linie:

Adică, fișierele noastre de proiect pur și simplu nu au fost indexate.

Situația este următoarea: susținută oficial VueJs este în plugin SonarJScine este responsabil pentru Javascript.

Dar acest suport nu este în plugin SonarTS pentru TS, despre care a fost deschis un bilet oficial în bug tracker Sonar'A:

Iată câteva răspunsuri de la unul dintre reprezentanții dezvoltatorilor SonarQube, care confirmă acest fapt.

Dar totul a funcționat pentru noi, obiectezi. Da este, hai să încercăm puțin „hack”.
Dacă există sprijin .vue-fisare Sonar„Oh, atunci hai să încercăm să-i spunem să-i considere ca manuscris dactilografiat.

Să adăugăm un parametru:

sonar-proiect.proprietati:

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

Să lansăm scanerul:

Și, voila, totul a revenit la normal, și cu un singur profil doar pentru manuscris dactilografiat. Adică am reușit să rezolvăm problema în suport VueJs+TS pentru soundQube.

Să încercăm să mergem mai departe și să îmbunătățim puțin informațiile de acoperire.

Ce am făcut până acum:

adăugat la proiect Sonar-scaner;
înființat există pentru a genera informații de acoperire;
configurat Sonar-scaner;
a rezolvat problema suportului .vue-fișiere + manuscris dactilografiat.

Pe lângă acoperirea testelor, există și alte criterii utile interesante pentru calitatea codului, de exemplu, duplicarea codului și numărul de linii (implicate în calculul coeficienților aferenți complexității codului) ale proiectului.

În implementarea actuală a pluginului pentru lucrul cu TS (SonarTS) nu va funcționa CPD (Detector de copiere și lipire) și numărarea liniilor de cod .vue-fisare.

Pentru a crea o situație sintetică de duplicare a codului, pur și simplu duplicați fișierul component cu un alt nume și, de asemenea, adăugați-l la cod principale.ts o funcție dummy și duplicați-o cu un alt nume. Pentru a verifica duplicarea ca în .vueși în .ts -fisare.

principale:

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

Pentru a face acest lucru, trebuie să comentați temporar linia de configurare:

sonar-proiect.proprietati:

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

Să repornim scanerul împreună cu testarea:

yarn test && yarn run sonar

Desigur, acoperirea noastră va scădea, dar acum nu ne interesează asta.

În ceea ce privește duplicarea liniilor de cod, vom vedea:

Pentru a verifica vom folosi CPD-utilitate - jscpd:

npx jscpd src

Pentru linii de cod:

Poate că acest lucru va fi rezolvat în versiunile viitoare de plugin SonarJS(TS). Aș dori să remarc că încep treptat să îmbine aceste două pluginuri într-unul singur SonarJS, ceea ce mi se pare corect.

Acum am vrut să iau în considerare opțiunea de îmbunătățire a informațiilor de acoperire.

Până acum putem vedea acoperirea testelor în termeni procentuali pentru întregul proiect și pentru fișiere în special. Dar este posibil să extindeți acest indicator cu informații despre cantitate unitate-teste pentru proiect, cat si in contextul dosarelor.

Există o bibliotecă care poate există-conversia raportului în format pentru Sonar'A:
date de testare generice - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Să instalăm această bibliotecă în proiectul nostru:

yarn add jest-sonar-reporter

Și adăugați-l la configurație există:

package.json:

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

Acum să rulăm testul:

yarn test

După care va fi creat un fișier în rădăcina proiectului test-report.xml.

Să-l folosim în configurație Sonar'A:

sonar-proiect.proprietati:

…
sonar.testExecutionReportPaths=test-report.xml
…

Și reporniți scanerul:

yarn run sonar

Să vedem ce s-a schimbat în interfață Sonar'A:

Și nimic nu s-a schimbat. Cert este că Sonar nu consideră fișierele descrise în raportul Jest drept fișiere unitate-teste. Pentru a corecta această situație, folosim parametrul de configurare Sonar sonar.teste, în care vom indica în mod explicit folderele cu teste (avem doar unul deocamdată):

sonar-proiect.proprietati:

…
sonar.tests=src/components/__tests__
…

Să repornim scanerul:

yarn run sonar

Să vedem ce s-a schimbat în interfață:

Acum am văzut numărul nostru unitate-teste și, după ce a eșuat făcând clic în interior, putem vedea distribuția acestui număr între fișierele de proiect:

Concluzie

Deci, ne-am uitat la un instrument de analiză continuă soundQube. Am integrat cu succes în el un proiect scris în VueJs+TS. S-au rezolvat unele probleme de compatibilitate. Am crescut conținutul informațional al indicatorului de acoperire a testului. În acest articol am examinat doar unul dintre criteriile de calitate a codului (poate unul dintre cele principale), dar soundQube acceptă alte criterii de calitate, inclusiv testarea de siguranță. Dar nu toate aceste caracteristici sunt complet disponibile în comunitate-versiuni. Una dintre caracteristicile interesante și utile este integrarea soundQube cu diverse sisteme de gestionare a depozitelor de coduri, cum ar fi GitLab și BitBucket. A preveni merge pull(merge) cerere„a către ramura principală a depozitului atunci când acoperirea este degradată. Dar aceasta este o poveste pentru un articol complet diferit.

PS: Tot ceea ce este descris în articol sub formă de cod este disponibil în furculița mea.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Folosiți platforma SonarQube:

26,3%Da5
15,8%Nr.3
15,8%Am auzit de această platformă și vreau să folosesc3
10,5%Am auzit de această platformă și nu vreau să o folosesc2
0,0%Folosesc o altă platformă0
31,6%Prima dată când aud de ea6

Au votat 19 utilizatori. 3 utilizatori s-au abținut.

Sursa: www.habr.com

Integrarea proiectului VueJS+TS cu SonarQube

Concluzie

Folosiți platforma SonarQube:

Adauga un comentariu Anula răspuns