Platformo aktivno uporabljamo pri svojem delu soundQube ohraniti kakovost kode na visoki ravni. Pri integraciji enega od projektov, zapisanih v VueJs+tipkopis, so nastale težave. Zato bi vam rad podrobneje povedal, kako nam jih je uspelo rešiti.

V tem članku bomo govorili, kot sem napisal zgoraj, o platformi SonarQube. Malo teorije - kaj je na splošno, za tiste, ki prvič slišijo za to:

soundQube (nekdanji sonar) je odprtokodna platforma za stalno preverjanje in merjenje kakovosti kode.
Podpira analizo kode in odkrivanje napak po pravilih programskih standardov MISRA C, MISRA C++, MITER/CWE in CERT Secure Coding Standards. Prav tako lahko prepozna napake s seznamov OWASP Top 10 in CWE/SANS Top 25 programskih napak.
Kljub dejstvu, da platforma uporablja različna že pripravljena orodja, SonarQube zmanjša rezultate na eno samo nadzorno ploščo, pri čemer hrani zgodovino izvajanj in vam tako omogoča, da vidite splošni trend sprememb v kakovosti programske opreme med razvojem.

Več podrobnosti najdete na uradna spletna stran

Podprtih je veliko število programskih jezikov. Sodeč po podatkih iz zgornje povezave gre za več kot 25 jezikov. Če želite podpreti določen jezik, morate namestiti ustrezen vtičnik. Različica skupnosti vključuje vtičnik za delo Javascript (vključno s typeсript), čeprav wiki pravi nasprotno. zadaj Javascript odgovori vtičnikov SonarJS, za Typescript SonarTS zaporedju.

Uradni odjemalec se uporablja za pošiljanje informacij o pokritosti sonarqube-skener, ki z uporabo nastavitev iz config-file, te podatke pošlje strežniku soundQube za nadaljnjo konsolidacijo in združevanje.

Za Javascript obstaja npm ovoj. Torej, začnimo izvajati korak za korakom soundQube в Vue-uporaba projekta Tipkovnica.

Za namestitev strežnika soundQube izkoristimo docker-compose.

sonar.yaml:

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

Kosilo:

docker-compose -f sonar.yml up

Nato soundQube bo na voljo na: http://localhost:9001 .

V njem še ni projektov in to je pošteno. To situacijo bomo popravili. Za uradni primer sem vzel projekt VueJS+TS+Jest. Upognite ga k sebi:

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

Najprej moramo namestiti odjemalca soundQubeki se imenuje sonar-skenerza npm obstaja ovoj:

yarn add sonarqube-scanner

In takoj dodajte ukaz v skripte delati z njim.

package.json:

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

Nato morate za delovanje optičnega bralnika nastaviti nastavitve projekta v posebni datoteki. Začnimo z osnovami.

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 - naslov sonar'A;
• sonar.projectKey – edinstven identifikator projekta na strežniku sonar'A;
• sonar.projectName – ime, ki ga lahko kadarkoli spremenite, saj je projekt identificiran z projectKey;
• sonar.viri – mapa z viri, običajno to src, lahko pa karkoli. Ta mapa je nastavljena glede na korensko mapo, ki je mapa, iz katere se zažene optični bralnik;
• sonar.testi – parameter, ki gre v tandemu s prejšnjim. To je mapa, kjer se nahajajo testi. V tem projektu te mape ni, test pa se nahaja zraven testirane komponente v mapi 'Test‘, zato ga bomo za zdaj prezrli in uporabili naslednji parameter;
• sonar.test.vključkov – pot za teste z masko, lahko je več elementov, navedenih med seboj z vejicami;
• sonar.sourceEncoding – kodiranje izvornih datotek.

Za prvi zagon optičnega bralnika je vse pripravljeno, razen glavnega predhodnega dejanja: zagona samega testnega motorja, da lahko ustvari podatke o pokritosti, ki jih bo optični bralnik kasneje uporabil.

Toda za to morate konfigurirati preskusni mehanizem za ustvarjanje teh informacij. V tem projektu je testni motor obstaja. In njegove nastavitve so v ustreznem razdelku datoteke paket.json.

Dodajmo te nastavitve:

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

To pomeni, da sami nastavimo zastavo za potrebo po izračunu pokritosti in vir (skupaj z izjemami), na podlagi katerega bo oblikovana.

Zdaj pa zaženimo test:

yarn test

Videli bomo naslednje:

Razlog je v tem, da v sami komponenti ni kode. Popravimo to.

HelloWorld.vue:

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

To bo dovolj za izračun kritja.

Po ponovnem zagonu testa se bomo prepričali o tem:

Na zaslonu bi morali videti informacije o pokritosti, v mapi projekta pa bo ustvarjena mapa pokritost z informacijami o pokritosti testov v univerzalni obliki LCOV (razširitev LTP GCOV).

Gcov je prosto distribuiran pripomoček za preverjanje pokritosti kode. Gcov generira natančno število izvedb za vsak stavek v programu in vam omogoča dodajanje opomb k izvorni kodi. Gcov je standardni pripomoček kot del paketa GCC.
Lcov - grafični vmesnik za gcov. Sestavlja datoteke gcov za več izvornih datotek in izdela nabor strani HTML s kodo in informacijami o pokritosti. Strani so ustvarjene tudi za lažjo navigacijo. Lcov podpira pokritost nizov, funkcij in vej.

Ko so testi končani, bodo informacije o pokritosti na voljo v coverage/lcov.info.
Moramo povedati sonar'Kje ga lahko dobim? Zato dodajmo naslednje vrstice njegovi konfiguracijski datoteki. Vendar obstaja ena točka: projekti so lahko večjezični, torej v mapi src obstajajo izvorne kode za več programskih jezikov in pripadnost enemu ali drugemu, po drugi strani pa je uporaba enega ali drugega vtičnika določena z njegovo razširitvijo. Informacije o pokritosti se lahko shranijo na različnih mestih za različne programske jezike, tako da ima vsak jezik svoj razdelek za to nastavitev. Naš projekt uporablja Tipkovnica, zato potrebujemo razdelek z nastavitvami samo za to:

sonar-project.properties:

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

Vse je pripravljeno za prvi zagon skenerja. Rad bi opozoril, da je projekt sonar'e se ustvari samodejno, ko prvič zaženete skener za določen projekt. V naslednjih časih se bodo informacije zbirale, da bi lahko videli dinamiko sprememb parametrov projekta skozi čas.

Torej, uporabimo ukaz, ustvarjen prej v paket.json:

yarn run sonar 

Opomba: lahko uporabite tudi parameter -X za podrobnejše beleženje.

Če je bil skener prvič zagnan, se bo najprej prenesla binarna datoteka samega skenerja. Po tem se zažene in začne skenirati strežnik sonar’a za nameščene vtičnike, s čimer se izračuna podprti jezik. Naloženi so tudi različni drugi parametri za njegovo delovanje: profili kakovosti, aktivna pravila, repozitorij metrik, pravila strežnika.

Opomba: Ne bomo se podrobneje ukvarjali z njimi v okviru tega članka, vendar se lahko vedno obrnete na uradne vire.

Nato se začne analiza mape src za razpoložljivost izvornih datotek za vse (če določen ni izrecno naveden) podprte jezike z njihovim kasnejšim indeksiranjem.

Sledijo različne druge analize, na katere se v tem članku ne osredotočamo (na primer linting, odkrivanje podvajanja kod itd.).

Čisto na koncu dela skenerja se vse zbrane informacije združijo, arhivirajo in pošljejo na strežnik.

Po tem že lahko vidimo, kaj se je zgodilo v spletnem vmesniku:

Kot lahko vidimo, je nekaj delovalo in celo kaže nekakšno pokritost, vendar se ne ujema z našo obstaja- poročilo.

Ugotovimo. Oglejmo si projekt podrobneje, kliknite na vrednost pokritosti in "padite" v podrobno poročilo o datoteki:

Tukaj vidimo poleg glavne pregledane datoteke HelloWorld.vue, obstaja tudi datoteka main.ts, kar pokvari celotno sliko pokritosti. A kako to, da smo ga izločili iz izračuna kritja. Ja, vse je prav, vendar je bilo na nivoju obstaja, vendar ga je skener indeksiral, tako da je končal v njegovih izračunih.

Popravimo to:

sonar-project.properties:

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

Rad bi pojasnil: poleg map, ki so določene v tem parametru, so dodane tudi vse mape, navedene v parametru sonar.test.vključkov.

Po zagonu optičnega bralnika vidimo pravilne informacije:

Poglejmo naslednjo točko - Kvalitetni profili. Zgoraj sem govoril o podpori sonarv več jezikih hkrati. Točno to vidimo. Vemo pa, da je naš projekt zapisan v TS, zakaj bi torej optični bralnik obremenjevali z nepotrebnimi manipulacijami in pregledi. Jezik za analizo bomo nastavili tako, da bomo konfiguracijski datoteki dodali še en parameter sonar'A:

sonar-project.properties:

...
sonar.language=ts
...

Ponovno zaženimo skener in poglejmo rezultat:

Pokritost je popolnoma izginila.

Če pogledamo dnevnik optičnega bralnika, lahko vidimo naslednjo vrstico:

To pomeni, da naše projektne datoteke preprosto niso bile indeksirane.

Stanje je naslednje: uradno podprto VueJs je v vtičniku SonarJSkdo je odgovoren za Javascript.

Vendar te podpore ni v vtičniku SonarTS za TS, o katerem je bila v sledilniku hroščev odprta uradna vstopnica sonar'A:

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

Tukaj je nekaj odgovorov enega od predstavnikov razvijalcev SonarQube, ki potrjujejo to dejstvo.

Ampak pri nas je vse delovalo, ugovarjate. Ja res je, poskusimo malo "kramp".
Če obstaja podpora .vue-datoteke sonar’om, potem mu poskusimo povedati, naj jih obravnava kot Tipkovnica.

Dodajmo parameter:

sonar-project.properties:

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

Zaženimo skener:

In, voila, vse je spet normalno in samo z enim profilom za Tipkovnica. Se pravi, uspelo nam je rešiti problem v podpori VueJs+TS za soundQube.

Poskusimo iti dlje in nekoliko izboljšati informacije o pokritosti.

Kaj smo naredili do sedaj:

• dodan v projekt sonar- skener;
• nastaviti obstaja za ustvarjanje informacij o pokritosti;
• konfiguriran sonar- skener;
• rešil težavo s podporo .vue-datoteke + Tipkovnica.

Poleg pokritosti testa obstajajo tudi druga zanimiva uporabna merila za kakovost kode, na primer podvajanje kode in število vrstic (vključenih v izračun koeficientov, povezanih s kompleksnostjo kode) projekta.

V trenutni izvedbi vtičnika za delo z TS (SonarTS) ne bo delovalo CPD (Copy Paste Detector) in štetje vrstic kode .vue-datoteke.

Če želite ustvariti sintetično situacijo podvajanja kode, preprosto podvojite komponentno datoteko z drugim imenom in jo prav tako dodajte kodi main.ts navidezno funkcijo in jo podvojite z drugim imenom. Za preverjanje podvajanja kot v .vue, in v .ts -datoteke.

main.ts:

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

Če želite to narediti, morate začasno komentirati konfiguracijsko vrstico:

sonar-project.properties:

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

Ponovno zaženimo skener skupaj s testiranjem:

yarn test && yarn run sonar

Seveda nam bo pokritost padla, ampak zdaj nas to ne zanima.

Kar zadeva podvajanje vrstic kode, bomo videli:

Za preverjanje bomo uporabili CPD-pripomoček – jscpd:

npx jscpd src

Za vrstice kode:

Morda bo to rešeno v prihodnjih različicah vtičnika SonarJS(TS). Rad bi opozoril, da postopoma začenjajo združevati ta dva vtičnika v enega SonarJS, kar se mi zdi pravilno.

Zdaj sem želel razmisliti o možnosti izboljšanja informacij o pokritosti.

Zaenkrat lahko vidimo pokritost testa v odstotkih za celoten projekt in še posebej za datoteke. Toda ta kazalnik je mogoče razširiti s podatki o količini Enota-testi za projekt, kot tudi v kontekstu datotek.

Obstaja knjižnica, ki lahko obstaja-pretvori poročilo v format za sonar'A:
generični testni podatki - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Namestimo to knjižnico v naš projekt:

yarn add jest-sonar-reporter

In ga dodajte konfiguraciji obstaja:

package.json:

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

Zdaj pa zaženimo test:

yarn test

Po tem bo ustvarjena datoteka v korenu projekta testno poročilo.xml.

Uporabimo ga v konfiguraciji sonar'A:

sonar-project.properties:

…
sonar.testExecutionReportPaths=test-report.xml
…

In znova zaženite skener:

yarn run sonar

Poglejmo, kaj se je spremenilo v vmesniku sonar'A:

In nič se ni spremenilo. Dejstvo je, da Sonar datotek, opisanih v poročilu Jest, ne obravnava kot datoteke Enota-testi. Da bi popravili to situacijo, uporabimo konfiguracijski parameter sonar sonar.testi, v katerem bomo eksplicitno označili mape s testi (zaenkrat imamo samo eno):

sonar-project.properties:

…
sonar.tests=src/components/__tests__
…

Ponovno zaženimo skener:

yarn run sonar

Poglejmo, kaj se je spremenilo v vmesniku:

Zdaj smo videli število naših Enota-teste in če s klikom noter ne uspemo, lahko vidimo porazdelitev tega števila med projektnimi datotekami:

Zaključek

Torej, pogledali smo orodje za kontinuirano analizo soundQube. Vanj smo uspešno integrirali projekt, zapisan v VueJs+TS. Odpravljene so nekatere težave z združljivostjo. Povečali smo informativnost indikatorja pokritosti testa. V tem članku smo preučili samo eno od meril kakovosti kode (morda eno glavnih), vendar soundQube podpira druga merila kakovosti, vključno s testiranjem varnosti. Vendar vse te funkcije niso v celoti na voljo v skupnost-različice. Ena od zanimivih in uporabnih funkcij je integracija soundQube z različnimi sistemi za upravljanje repozitorija kod, kot sta GitLab in BitBucket. Preprečiti merge pull (združiti) zahtevo’a v glavno vejo repozitorija, ko se pokritost poslabša. Toda to je zgodba za povsem drug članek.

PS: Vse, kar je v članku opisano v obliki kode, je na voljo v moje vilice.

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Ali uporabljate platformo SonarQube:

• 26,3%Da5

• 15,8%št.3

• 15,8%Slišal sem za to platformo in jo želim uporabiti3

• 10,5%Slišal sem za to platformo in je ne želim uporabljati2

• 0,0%Uporabljam drugo platformo0

• 31,6%Prvič slišim zanjo6

Glasovalo je 19 uporabnikov. 3 uporabnika sta se vzdržala.

Vir: www.habr.com