I vårt arbeid bruker vi aktivt plattformen SonarQube for å opprettholde kodekvalitet på høyt nivå. Under integreringen av et prosjekt skrevet i VueJs+Typescript, oppstod det problemer. Derfor vil jeg gjerne forklare mer detaljert hvordan vi klarte å løse dem.

I denne artikkelen handler det, som nevnt tidligere, om plattformen SonarQube. Litt teori — hva det egentlig er, for de som hører om det for første gang:

SonarQube (tidligere Sonar) — er en plattform med åpen kildekode for kontinuerlig analyse (eng. continuous inspection) og måling av kodekvaliteten.
Den støtter kodeanalyse og feiloppdagelse i henhold til reglene for programmeringsstandardene MISRA C, MISRA C++, MITRE/CWE og CERT Secure Coding Standards. Den kan også gjenkjenne feil fra OWASP Top-10 og CWE/SANS Top-25 liste over programmeringsfeil.
Selv om plattformen bruker ulike ferdige verktøy, komprimerer SonarQube resultatene til et samlet informasjonspanel (eng. dashboard), og fører en historikk over kjøringer, noe som gir oss muligheten til å se den generelle trenden i endringene av programvarekvalitet gjennom utviklingen.

Mer informasjon kan finnes på den offisielle nettsiden

Det støttes et stort antall programmeringsspråk. Ifølge informasjonen fra lenken ovenfor — er det mer enn 25 språk. For å støtte et spesifikt språk må den aktuelle pluginnen installeres. Community-versjonen inkluderer en plugin for å jobbe med Javascript (inkludert typesсript), selv om det står noe annet i wikin. Dette Javascript støttes av pluginnen SonarJS, og for Typescript SonarTS henholdsvis.

For å sende dekning data brukes den offisielle klienten sonarqube-scanner, som, med innstillinger fra config-filen, sender disse dataene til serveren SonarQube for videre konsolidering og aggregasjon.

For Javascript det finnes npm-wrapper. Så, la oss begynne med steg-for-steg implementasjonen av SonarQube i Vue-prosjektet som bruker Typescript.

For å sette opp serveren vil vi bruke SonarQube sonar.yaml docker-compose.

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

Oppstart:

docker-compose -f sonar.yml up

Etter dette

vil være tilgjengelig på adressen – SonarQube Så langt finnes det ingen prosjekter, og det er berettiget. Vi skal rette opp i denne situasjonen. Jeg har basert det på det offisielle eksempelprosjektet for http://localhost:9001 .

VueJS+TS+Jest . La oss klone det:git clone https://github.com/vuejs/vue-test-utils-typescript-example.git

Først må vi installere klienten

Først må vi installere klienten SonarQube, som kalles sonar-scanner, for npm har en omsluttende kode:

yarn add sonarqube-scanner

Og vi legger umiddelbart til kommandoen i scripts for å jobbe med det.

package.json:

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

Deretter, for at skanneren skal fungere, må prosjektinnstillingene angis i en spesiell fil. La oss begynne med det grunnleggende.

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 – adressen Sonar’a;
sonar.projectKey – den unike prosjektidentifikatoren på serveren Sonar’a;
sonar.projectName – navnet på prosjektet, som kan endres når som helst, ettersom prosjektidentifikasjonen skjer via projectKey;
sonar.sources – mappen med kildefiler, som vanligvis er src, men kan være hva som helst. Denne mappen angis i forhold til rotmappen, som er mappen hvor skanneren kjøres fra;
sonar.tests – parameteret som henger sammen med det forrige. Dette er mappen der testene befinner seg. I dette prosjektet finnes det ingen slik mappe, og testen ligger ved siden av den testede komponenten i mappen ‘test‘, så vi bortser fra det for nå og bruker det neste parameteret;
sonar.test.inclusions – banen for tester med bruk av et mønster, kan ha flere elementer som er adskilt med komma;
sonar.sourceEncoding – kodingen for kildefilene.

For den første kjøringen av skanneren er alt klart, bortsett fra den viktigste forberedende handlingen: å starte selve testmotoren for å generere informasjon om dekning, som skanneren senere vil bruke.

Men for dette må testmotoren konfigureres til å generere denne informasjonen. I dette prosjektet er testmotoren – Jest. Og innstillingene hans ligger i den relevante delen av filen. package.json.

La oss legge til disse innstillingene:

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

Det vil si at vi setter flagget for behovet for å beregne dekning og kilden (sammen med unntakene) som dekningen vil bli dannet ut ifra.

Nå kjører vi testen:

yarn test

Vi ser følgende:

Årsaken er at det ikke er noe egentlig kode i komponenten. La oss fikse dette.

HelloWorld.vue:

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

Dette vil være tilstrekkelig for å beregne dekning.

Etter å ha kjørt testen på nytt, vil vi bekrefte dette:

På skjermen skal vi se informasjon om dekning, og i prosjektmappen vil det bli opprettet en mappe dekning med informasjon om testdekning i et universelt format LCOV (LTP GCOV-utvidelse).

Gcov — et frittstående verktøy for å undersøke kode-dekning. Gcov genererer nøyaktige antall kjøringer for hver setning i programmet og lar deg legge til merknader til kildekoden. Gcov følger med som et standardverktøy i GCC-pakken.
Lcov — et grafisk grensesnitt for gcov. Det samler gcov-filer for flere kildefiler og genererer et sett med HTML-sider med kode og dekning informasjon. Det genereres også sider for å forenkle navigasjonen. Lcov støtter dekning av linjer, funksjoner og forgreninger.

Etter at testene er fullført, vil informasjonen om dekning befinne seg i coverage/lcov.info.
Vi må si Sonarhvor den skal hentes fra. Derfor legger vi til følgende linjer i konfigurasjonsfilen. Men det er et poeng: prosjektene kan være flerspråklige, det vil si at det i mappen src befinner seg kilder for flere programmeringsspråk og tilknytningen til et spesifikt språk og bruken av det spesifikke pluginet bestemmes av dets utvidelse. Og informasjon om dekning kan lagres på forskjellige steder for forskjellige programmeringsspråk, så derfor er det et eget seksjon for innstilling for hvert språk. Vårt prosjekt bruker Typescript, så vi trenger en innstillingsseksjon spesielt for det:

sonar-project.properties:

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

Alt er klart for første kjøring av skanneren. Jeg vil gjerne påpeke at prosjektet i Sonarautomatiskt opprettes ved første kjøring av skanneren for dette prosjektet. Ved påfølgende ganger vil informasjonen allerede bli akkumulert, slik at vi kan se dynamikken i endringene i prosjektparameterne over tid.

Så, la oss bruke kommandoen som ble laget tidligere i package.json:

yarn run sonar

Merk: du kan også bruke parameteren -X for mer detaljert logging.

Hvis skanneren ble kjørt for første gang, vil den først laste ned binæren for skanneren. Etter det starter den og begynner å skanne serveren Sonarfor installerte plugins, samtidig som den beregner støttede språk. Også ulike andre parametere for dens drift lastes ned: kvalitetsprofiler, aktive regler, metrikkrepository, serverregler.

Merk: Vi vil ikke gå nærmere inn på dem i denne artikkelen, men man kan alltid ta kontakt med offisielle kilder.

Videre begynner analysen av mappen src for å sjekke om det finnes kildefiler for alle (med mindre en bestemt programmeringsspråk er spesifisert) støttede programmeringsspråk, med påfølgende indeksering av dem.

Deretter kommer andre ulike analyser, som vi ikke fokuserer på i denne artikkelen (for eksempel som: linting, identifisering av kodeduplisering osv.).

På slutten av skannerens arbeid skjer det en aggregasjon av all innsamlet informasjon, arkivering og sending til serveren.

Etter dette kan vi se hva vi fikk i webgrensesnittet:

Som vi ser, har vi fått noe, og det viser til og med en viss dekning, men den samsvarer ikke med vår Jest-rapport.

La oss finde ut av dette. Vi ser nærmere på prosjektet, klikker på dekningens verdi, og "går inn" i den detaljerte rapporten om filene:

Her ser vi, i tillegg til den primære filen vi undersøker, HelloWorld.vue, finnes også filen main.ts, som ødelegger hele dekningen. Men hvordan kan det være, vi ekskluderte den fra dekningen. Ja, det er riktig, men det ble gjort på nivået Jest, men scanner indekserte den, så den havnet i beregningene.

La oss fikse dette:

sonar-project.properties:

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

Det er verdt å presisere: utover de mappene som er angitt i denne parameteren, legges også alle mapper som er oppført i parameteren sonar.test.inclusions.

Etter å ha kjørt scanneren ser vi allerede korrekt informasjon:

La oss gå gjennom neste punkt – Kvalitetsprofiler.Jeg nevnte tidligere at støtte for flere programmeringsspråk samtidig eksisterer. Dette er akkurat det vi observerer. Men vi vet at prosjektet er skrevet i SonarTS , så hvorfor belaste skanneren med unødvendige manipulasjoner og sjekker. Språket for analysen skal vi definere ved å legge til en annen parameter i konfigurasjonsfilen: Sonar... sonar.language=ts ...

sonar-project.properties:

La oss kjøre scanneren igjen og se resultatet:

Dekningen forsvant helt.

Hvis vi ser i loggen til skanneren, kan vi se følgende linje:

Det vil si at filene i prosjektet vårt bare ikke ble indeksert.

Situasjonen er som følger: den offisielle støtten for

VueJs finnes i pluginet , som svarer til SonarJSMen denne støtten finnes ikke i pluginet Javascript.

, noe som det er opprettet en offisiell ticket om i bug-tracker SonarTS for , så hvorfor belaste skanneren med unødvendige manipulasjoner og sjekker. Språket for analysen skal vi definere ved å legge til en annen parameter i konfigurasjonsfilen. Sonar... sonar.language=ts ...

Her er noen svar fra en av representantene fra utviklerne av SonarQube som bekrefter dette faktum.

Men alt fungerte jo for oss, vil du protestere. Ja, det stemmer, la oss prøve litt “å hacke”.
Hvis det er støtte .vue-filer Sonar’en, så la oss prøve å si til den at den skal vurdere dem som Typescript.

La oss legge til en parameter:

sonar-project.properties:

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

La oss kjøre skanneren:

Og, voila, alt har kommet tilbake til det normale, med bare ett profil for Typescript. Så, vi klarte å løse problemet med støtten for VueJs+TS for SonarQube.

La oss prøve å gå videre og forbedre informasjonen om dekning litt.

Hva har vi gjort så langt:

lagt til prosjektet Sonar-skanneren;
konfigurert Jest for å generere informasjon om dekning;
konfigurert Sonar-skanneren;
løst problemet med støtten til .vue-filer + Typescript.

I tillegg til testdekning er det andre interessante kriterier for programkvalitet, som f.eks. kode duplikering og antall linjer (som brukes i beregningen av koeffisienter relatert til kodekompleksitet) i prosjektet.

I den nåværende implementeringen av pluginen for arbeid med , så hvorfor belaste skanneren med unødvendige manipulasjoner og sjekker. Språket for analysen skal vi definere ved å legge til en annen parameter i konfigurasjonsfilen (SonarTS) vil ikke fungere CPD (Copy Paste Detector) og telling av linjer med kode .vue-filer.

For å skape en syntetisk situasjon for kode duplikering, bare dupliser en komponentfil med et annet navn, og legg til en dummy-funksjon i koden og dupliser den med et annet navn. For å sjekke duplikasjonen som i main.ts , så vel som i .vue.ts -filer. main.ts:

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

For dette må vi midlertidig kommentere ut konfigurasjonslinjen:

La oss starte skanneren på nytt sammen med testing:

sonar-project.properties:

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

yarn test && yarn run sonar

Selvfølgelig vil dekningen falle, men for nå er vi ikke interessert i dette.

Når det gjelder duplikering av linjer med kode, vil vi se:

For å kontrollere, la oss bruke

CPD -verktøyet –jscpd npx jscpd src:

For linjer med kode:

Dette kan løses i fremtidige versjoner av pluginene

SonarJS(TS) . Jeg vil påpeke at de gradvis begynner å slå sammen disse to pluginene til én, noe som, tror jeg, er riktig. SonarJSNå vil jeg gjerne se på muligheten for å forbedre informasjonen om dekning.

Så langt ser vi testdekning i prosent i hele prosjektet, og for filene spesielt. Men det er mulighet for å utvide dette tiltaket med informasjon om antall

unit -tester i prosjektet, samt på tvers av filene.Det finnes et bibliotek som kan

-rapporten konvertere til format for Jestgeneric test data Sonar... sonar.language=ts ...
La oss installere dette biblioteket i prosjektet vårt: — https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

La oss installere dette biblioteket i prosjektet vårt:

yarn add jest-sonar-reporter

Og vi legger det til i konfigurasjonen Jest:

package.json:

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

Nå skal vi kjøre testen:

yarn test

Etter det vil det bli opprettet en fil i rotmappen av prosjektet test-report.xml.

Vi bruker det i konfigurasjonen Sonar... sonar.language=ts ...

sonar-project.properties:

…
sonar.testExecutionReportPaths=test-report.xml
…

Og vi starter skanneren på nytt:

yarn run sonar

La oss se hva som har endret seg i grensesnittet Sonar... sonar.language=ts ...

Og ingenting har endret seg. Faktisk, Sonar vurderer ikke filene beskrevet i Jest-rapporten som filer -tester i prosjektet, samt på tvers av filene.-tester. For å løse denne situasjonen bruker vi konfigurasjonsparameteren Sonar sonar.tests, der vi eksplisitt angir mapper med tester (for tiden har vi bare en):

sonar-project.properties:

…
sonar.tests=src\/components\/__tests__
…

Vi starter skanneren på nytt:

yarn run sonar

La oss se hva som har endret seg i grensesnittet:

Nå har vi sett antall våre -tester i prosjektet, samt på tvers av filene.-tester og, ved å klikke inn, kan vi se fordelingen av dette tallet på prosjektfilene:

Konklusjon

Så, vi har sett på et verktøy for kontinuerlig analyse SonarQube. Vi integrerte prosjektet, som ble skrevet på VueJs+TS. Vi løste noen kompatibilitetsproblemer. Vi økte informasjonen i indikatoren for testdekning. I denne artikkelen har vi sett på bare ett av kvalitetskriteriene (kanskje et av de viktigste), men SonarQube støtter også andre kvalitetskriterier, inkludert sikkerhetstesting. Men ikke alle disse funksjonene er fullt tilgjengelige i community-versjonen. En av de interessante og nyttige mulighetene er integrasjoner SonarQube med forskjellige kodebehandlingssystemer, som GitLab og BitBucket. For å unngå merge pull(merge) requesttil hovedgreinen av depotet ved degradert dekning. Men det er en helt annen artikkel.

PS: Alt som er beskrevet i artikkelen i form av kode er tilgjengelig i min fork.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.