Në punën tonë, ne përdorim aktivisht platformën SonarQube për të mbajtur cilësinë e kodit në një nivel të lartë. Gjatë integrimit të njërit nga projektet, e shkruar në VueJs+Typescript, pati probleme. Prandaj, do të dëshiroja të flas më në detaje për se si arritëm t'i zgjidhim ato.

NĂ« kĂ«tĂ« artikull do tĂ« flasim, siç e pĂ«rmenda mĂ« lart, pĂ«r platformĂ«n SonarQube. Pak teori â çfarĂ« Ă«shtĂ« kjo nĂ« tĂ« vĂ«rtetĂ«, pĂ«r ata qĂ« e dĂ«gjojnĂ« pĂ«r herĂ« tĂ« parĂ«:
SonarQube (ish Sonar) â njĂ« platformĂ« me burim tĂ« hapur pĂ«r analiza tĂ« vazhdueshme dhe matjen e cilĂ«sisĂ« sĂ« kodit.
Përkrah analiza e kodit dhe kërkimi i gabimeve sipas rregullave të standardeve të programimit MISRA C, MISRA C++, MITRE/CWE dhe CERT Secure Coding Standards. Në të njëjtën kohë, di të njohë gabimet nga listat OWASP Top-10 dhe CWE/SANS Top-25 të gabimeve të programimit.
Megjithëse platforma përdor mjete të gatshme të ndryshme, SonarQube i ktheu rezultatet në një panel të vetëm informacioni, duke mbajtur historinë e ekzekutimeve dhe duke lejuar kështu të shohësh tendencën e përgjithshme të ndryshimit të cilësisë së softuerit gjatë zhvillimit.
Më shumë informacion mund të merret në
KĂ«tu pĂ«rkrahet njĂ« numĂ«r i madh gjuhĂ«sh programimi. Sipas informacionit nga lidhja mĂ« sipĂ«r â janĂ« mĂ« shumĂ« se 25 gjuhĂ«. PĂ«r tĂ« mbĂ«shtetur njĂ« gjuhĂ« tĂ« caktuar, Ă«shtĂ« e nevojshme tĂ« instalosh njĂ« plugin pĂ«rkatĂ«s. NĂ« versionin community pĂ«rfshihet njĂ« plugin pĂ«r tĂ« punuar me Javascript (pĂ«rfshirĂ« typesŃript), megjithatĂ« nĂ« wiki Ă«shtĂ« shkruar e kundĂ«rta. PĂ«r Javascript Ă«shtĂ« pĂ«rgjegjĂ«s plugin-i SonarJS, pĂ«r Typescript SonarTS pĂ«rkatĂ«sisht.
Për dërgimin e informacionit mbi mbulimin, përdoret klienti zyrtar sonarqube-scanner, i cili, duke përdorur cilësimet nga config-skedari, dërgon këto të dhëna në server SonarQube për konsolidim dhe agregim të mëtejshëm.
Për Javascript është . Tani, le të fillojmë implementimin hap pas hapi SonarQube në Vue-projekt, i cili përdor Typescript.
Për të vendosur serverin SonarQube do të përdorim docker-compose.
sonar.yaml:
version: '1'
services:
simplesample-sonar:
image: sonarqube:lts
ports:
- 9001:9000
- 9092:9092
network_mode: bridgeFillimi:
docker-compose -f sonar.yml upPas kĂ«saj SonarQube do tĂ« jetĂ« i aksesueshĂ«m nĂ« adresĂ«n â .

Për momentin, nuk ka projekte në të dhe kjo është e drejtë. Do të përpiqemi të rregullojmë këtë situatë. Si bazë, kam marrë projektin zyrtar të shembullit për VueJS+TS+Jest. Do ta klonojmë atë te ne:
git clone https://github.com/vuejs/vue-test-utils-typescript-example.gitSë pari, na nevojitet klienti SonarQube, i cili quhet sonar-scannerparaqet një problem npm ka një wrapper:
yarn add sonarqube-scannerDhe menjëherë do të shtojmë komandën në scripts për të punuar me të.
package.json:
{
âŠ
scripts: {
...
"sonar": "sonar-scanner"
...
},
âŠ
}Më pas, për të punuar skanerin, duhet të japim konfigurimin e projektit në një skedë të veçantë. Le të fillojmë me bazat.
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 â adresa Sonarâa;
- sonar.projectKey â identifikues unik i projektit nĂ« server Sonarâa;
- sonar.projectName â emri i tij, mund tĂ« ndryshohet nĂ« çdo moment, pasi identifikimi i projektit bĂ«het pĂ«rmes projectKey;
- sonar.sources â folderi me kodin burimor, zakonisht Ă«shtĂ« src, por mund tĂ« jetĂ« i çfarĂ«do. Ky folder caktohet nĂ« raport me folderin rrĂ«njor, i cili Ă«shtĂ« folderi nga ku Ă«shtĂ« nisur skaneri;
- sonar.tests â parametr qĂ« shoqĂ«rohet me tĂ« parin. Ky Ă«shtĂ« folderi ku ndodhen testet. NĂ« kĂ«tĂ« projekt, nuk ka njĂ« folder tĂ« tillĂ«, dhe testi Ă«shtĂ« pranĂ« komponentit tĂ« testuar nĂ« folderin âtestâ, prandaj pĂ«r momentin do ta injorojmĂ« dhe do tĂ« pĂ«rdorim parametrin tjetĂ«r;
- sonar.test.inclusions â rruga pĂ«r testet duke pĂ«rdorur maskĂ«n, mund tĂ« ketĂ« disa elementĂ« tĂ« listuar me ndarĂ«s nga presja;
- sonar.sourceEncoding â kodimi pĂ«r skedat burimore.
Për nisjen e parë të skanerit gjithçka është gati, përveç veprimit kryesor paraprak: nisjen e motorit të testimit për të gjeneruar informacionin mbi mbulimin, që do të përdoret më pas nga skaneri.
Por për këtë duhet të konfigurojmë motorin e testimit për të gjeneruar këtë informacion. Në këtë projekt, motori i testimit është Jest. Dhe konfigurimet e tij ndodhen në seksionin përkatës të skedës package.json.
Le të shtojmë këto konfigurime:
"collectCoverage": true,
"collectCoverageFrom": [
"src/**/*",
"!src/main.ts",
"!src/App.vue",
"!src/**/*.d.*",
"!src/**/*__tests__*"
],Pra, po caktojmë flamurin e nevojshëm për llogaritjen e mbulimit dhe burimin (bashkë me përjashtimet), mbi bazën e cilave do të formohet.
Tani le të nisnim testin:
yarn testDo të shohim këtë:

Arsyeja është se në vetë komponentin, në thelb, nuk ka kod. Ta rregullojmë këtë.
HelloWorld.vue:
...
methods: {
calc(n) {
return n + 1;
}
},
mounted() {
this.msg1 = this.msg + this.calc(1);
},
...Kjo do të jetë e mjaftueshme për të llogaritur mbulimin.
Pas ri-nisjes së testit, le të sigurohemi për këtë:

Në ekran duhet të shohim informacion mbi mbulimin, dhe në folderin e projektit do të krijohet një folder coverage me informacionin mbi mbulimin nga testet në formatin universial LCOV (zgjerimi i LTP GCOV).
Gcov â njĂ« mjet me shpĂ«rndarje tĂ« lirĂ« pĂ«r tĂ« hulumtuar mbulimin e kodit. Gcov gjeneron numrin e saktĂ« tĂ« ekzekutimeve pĂ«r çdo operator nĂ« program dhe lejon shtimin e anotimeve nĂ« kodin burimor. Gcov ofrohet si njĂ« mjet standard nĂ« paketĂ«n GCC.
Lcov â njĂ« ndĂ«rfaqe grafike pĂ«r gcov. Ai mbledh skedarĂ«t gcov pĂ«r disa skedarĂ« burimorĂ« dhe krijon njĂ« paketĂ« faqesh HTML me kodin dhe informacionin mbi mbulimin. Gjithashtu gjenerohen faqe pĂ«r tĂ« thjeshtuar navigimin. Lcov mbĂ«shtet mbulimin e linjave, funksioneve dhe degĂ«ve.
Pas ekzekutimit të testeve informacioni mbi mbulimin do të ndodhet në coverage/lcov.info.
Na duhet të themi Sonarku ta marrim. Prandaj do të shtojmë rreshtat e mëposhtëm në skedarin e tij të konfigurimit. Por ka një moment: projektet mund të jenë multilinguale, domethënë në dosjen src janë burimet për disa gjuhë programimi dhe përkatësia ndaj asaj ose asaj, dhe përdorimi i ndonjë plugini të tillë, përcaktohet nga zgjatja e tij. Dhe informacioni mbi mbulimin mund të ruhet në vende të ndryshme për gjuhë të ndryshme programimi, prandaj për çdo GP ka një seksion të vetin për konfigurimin e këtij. Projekti ynë përdor Typescript, prandaj na duhet një seksion konfigurimi pikërisht për të:
sonar-project.properties:
sonar.typescript.coveragePlugin=lcov
sonar.typescript.lcov.reportPaths=coverage/lcov.infoTë gjitha janë gati për ekzekutimin e parë të skanerit. Dua të vë në dukje se projekti në Sonarkrijohet automatikisht gjatë ekzekutimit të parë të skanerit për këtë projekt. Në herët e mëpasshme informacioni tashmë do të akumulohet, për të parë dinamikën e ndryshimit të parametrave të projektit në kohë.
Pra, le të përdorim komandën, të krijuar më parë në package.json:
yarn run sonar Vërejtje: mund të përdorni gjithashtu parametrin -X për shkarkime më të detajuara.
Nëse ekzekutimi i skanerit ishte për herë të parë, përpara se të ekzekutohet, do të shkarkohet binari i vet skanerit. Pasi të shkarkohet, ai ndizet dhe fillon të skanojë serverin Sonarpër plugins të instaluara, duke llogaritur kështu GP-të e mbështetura. Gjithashtu shkarkohen parametra të tjerë të ndryshëm për funksionimin e tij: profile të cilësisë, rregullat aktive, repositorinë e metrikave, rregullat e serverit.


Vërejtje: në to nuk do të ndalemi shumë në kuadër të këtij artikulli, por gjithmonë mund të konsultoheni me burimet zyrtare.
Pas kësaj fillon analiza e dosjes src për të kontrolluar disponimin e skedarëve burim për të gjitha (nëse nuk është dhënë ndonjë gjuhë specifike) gjuhët e programimit të mbështetura, me indeksimin e tyre të mëvonshëm.

Më pas do të pasojnë analiza të tjera të ndryshme, në të cilat nuk e theksojmë vëmendjen në këtë artikull (p.sh., si: linting, përcaktimi i kopjave të kodit, etj.).
Në fund të punës së skanerit ndodh agregimi i të gjithë informacionit të mbledhur, arkivimi dhe dërgimi i tij në server.
Pas kësaj, ne mund të shohim çfarë morëm në ndërfaqen e uebit:

Siç shohim, diçka është realizuar, dhe madje tregon njëfarë mbulimi, por ai nuk përputhet me tonë Jest-raportin.
Le të kuptojmë. Të shohim projektin më në detaje, të klikojmë mbi vlerën e mbulimit dhe "të zhytim" në raportin e detajuar për skedarët:

Këtu ne shohim përveç skedarit kryesor të hetuar HelloWorld.vue, i pranishëm është edhe skedari main.ts, i cili prish të gjithë imazhin e mbulimit. Por si është e mundur, ne e kemi përjashtuar atë nga llogaritja e mbulimit. Po, e saktë, por kjo është bërë në nivelin Jest, por skaneri e ka indeksuar atë, prandaj ai përfshihet në llogaritjet e tij.
Le të korrigjojmë këtë:
sonar-project.properties:
...
sonar.exclusions=src/main.ts
...Dëshiroj të bëj një sqarim: përveç atyre dosjeve që janë përcaktuar në këtë parametër, gjithashtu shtohen të gjitha dosjet e listuara në parametrin sonar.test.inclusions.
Pasi të nisni skanerin, shohim tani informacion të saktë:


Të diskutojmë për aspektin tjetër - Profilet e cilësisë. E kam thënë më sipër për mbështetje të multiple gjuhëve të programimit njëkohësisht. Kjo është pikërisht ajo që shohim. Por ne e dimë se projekti ynë është shkruar në Sonar, prandaj pse ta ngarkojmë skanerin me manipulime dhe kontrolle të panevojshme. Gjuhën për analizë do ta përcaktojmë duke shtuar një parametër tjetër në skedarin e konfigurimit TS: Sonar... sonar.language=ts ...
sonar-project.properties:
Sërish do të nisni skanerin dhe të shihni rezultatin:Mbulimi është zhdukur për tërësisht.

Nëse shohim në logun e skanerit, mund të shohim rreshtin e mëposhtshëm:
Pra, skedarët e projektit tonë thjesht nuk ishin indeksuar.
![]()
Situata është si më poshtë: mbështetje zyrtare për
VueJs ka në pluginin , i cili përgjigjet për SonarJSPor kjo mbështetje nuk është në pluginin Javascript.

, për të cilën është regjistruar një ticket zyrtar në bug-tracker SonarTS për TSJa disa përgjigje nga njëra nga përfaqësuesit e zhvilluesve të SonarQube, që konfirmojnë këtë fakt. Sonar... sonar.language=ts ...
Por gjithçka po na punonte, do të kundërshtoni ju. Po, kështu është, le të përpiqemi pak


âta hakerojmĂ«â NĂ«se ka mbĂ«shtetje pĂ«r.
.vue -skedarë-skedar Sonaratë, atëherë le të përpiqemi t'i themi që t'i shqyrtojë ato si Typescript.
Shtojmë parametrin:
sonar-project.properties:
...
sonar.typescript.file.suffixes=.ts,.tsx,.vue
...TĂ« nisim skanerin:

Dhe, voilà , gjithçka u rikthye në rregull, dhe me një profil vetëm për Typescript. Kështu që arritëm të zgjidhim problemin në mbështetje VueJs+TS për SonarQube.
Të përpiqemi të shkojmë më tej dhe pak të përmirësojmë informacionin mbi mbulimin.
ĂfarĂ« kemi bĂ«rĂ« deri tani:
- shtuar në projekt Sonar-skanerin;
- konfiguruar Jest për formimin e informacionit mbi mbulimin;
- konfiguruar Sonar-skanerin;
- zgjidhur problemin e mbështetjes -skedarë-fileve + Typescript.
Përveç mbulimit me teste, ka kritere të tjera interesante të cilësisë së kodit, për shembull, përsëritja e kodit dhe numri i linjave (pjesëmarrës në llogaritjen e indekseve që lidhen me kompleksitetin e kodit) të projektit.
Në implementimin aktual të plugin-it për punuar me TS (SonarTS) nuk do të funksionojë CPD (Copy Paste Detector) dhe numërimi i linjave të kodit -skedarë-fileve.
PĂ«r tĂ« krijuar njĂ« situatĂ« sintetike pĂ«r pĂ«rsĂ«ritjen e kodit, thjesht do tĂ« dyfishojmĂ« skedarin e komponentit me njĂ« emĂ«r tjetĂ«r, gjithashtu do tĂ« shtojmĂ« nĂ« kod main.ts njĂ« funksion boĆ dhe do ta dyfishojmĂ« me njĂ« emĂ«r tjetĂ«r. PĂ«r tĂ« kontrolluar pĂ«rsĂ«ritjen si nĂ« -skedarĂ«, ashtu edhe nĂ« .ts -skedarĂ«t.
main.ts:
...
function name(params:string): void {
console.log(params);
}
...Për këtë, është e nevojshme të komentojmë përkohësisht rreshtin e konfigurimit:
sonar-project.properties:
...
sonar.exclusions=src/main.ts
...Të ri-nisim skanerin së bashku me testimin:
yarn test && yarn run sonarSigurisht që na do të bien mbulimi, por tani për ne kjo nuk është interesante.
Në aspektin e përsëritjes së linjave të kodit do të shohim:

PĂ«r verifikim, do tĂ« pĂ«rdorim CPD-utilitarin â jscpd:
npx jscpd src
Për linjat e kodit:

Mundësisht, kjo do të zgjidhet në versionet e ardhshme të plugin-eve SonarJS(TS). Dua të theksoj se ata gradualisht po fillojnë të kombinojnë këto dy plugin-e në një SonarJS, gjë që mendoj se është e saktë.
Tani do të doja të shqyrtoja mundësinë e përmirësimit të informacionit mbi mbulimin.
Derisa ne shohim mbulimin me teste në përqindje, në të gjithë projektin, dhe sipas skedarëve në veçanti. Por ka mundësi për të zgjeruar këtë tregues me informacionin mbi numrin unit-testeve sipas projektit, si dhe në aspektin e skedarëve.
Ka një bibliotekë që di Jest-raportin ta konvertojë në formatin për Sonar... sonar.language=ts ...
generic test data â .
Të instalojmë këtë bibliotekë në projektin tonë:
yarn add jest-sonar-reporterDhe ta shtojmë në konfigurim Jest:
package.json:
âŠ
"testResultsProcessor": "jest-sonar-reporter"
âŠTani tĂ« ekzekutojmĂ« testin:
yarn testPas së cilës në rrënjën e projektit do të krijohet një skedar test-report.xml.
Ta angazhojmë atë në konfigurim Sonar... sonar.language=ts ...
sonar-project.properties:
âŠ
sonar.testExecutionReportPaths=test-report.xml
âŠDhe tĂ« ri-nisim skanerin:
yarn run sonarLet's see what has changed in the interface Sonar... sonar.language=ts ...

And nothing has changed. The fact is that Sonar does not consider the files described in the Jest report as files unit-tests. To fix this situation, we will use a configuration parameter Sonar sonar.tests, in which we will explicitly specify the folders with tests (we have only one so far):
sonar-project.properties:
âŠ
sonar.tests=src/components/__tests__
âŠLet's restart the scanner:
yarn run sonarLet's see what has changed in the interface:

Now we can see the number of our unit-tests and, by clicking inside, we can see the distribution of this number across project files:

Përfundim
So, we reviewed the tool for continuous analysis SonarQube. Successfully integrated it with a project written in VueJs+TS. Resolved some compatibility issues. Increased the informativeness of the coverage indicator. In this article, we covered only one of the criteria for code quality (possibly one of the main ones), but SonarQube it also supports other quality criteria, including security testing. However, not all of these capabilities are fully available in the community-version. One of the interesting and useful features is the integrations SonarQube with various code repository management systems, such as GitLab and BitBucket. To prevent merging a pull requestinto the main branch of the repository when coverage degrades. But that's a story for a completely different article.
PS: Everything described in the article in code form is available in .
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
Do you use the SonarQube platform:
26,3%Po5
15,8%Jo3
15,8%I've heard about this platform and want to use it
10,5%I've heard about this platform and do not want to use it
0,0%I use another platform
31,6%I've never heard of it
19 users voted. 3 users abstained.
Burimi: habr.com
