Ons gebruik die platform aktief in ons werk klankQube om kodekwaliteit op 'n hoë vlak te handhaaf. By die integrasie van een van die projekte wat in geskryf is VueJs+Typskrif, probleme het ontstaan. Daarom wil ek u in meer besonderhede vertel hoe ons dit reggekry het om dit op te los.

In hierdie artikel sal ons praat, soos ek hierbo geskryf het, oor die SonarQube-platform. 'n Bietjie teorie - wat dit in die algemeen is, vir diegene wat vir die eerste keer daarvan hoor:

klankQube (voormalige sonar) is 'n oopbronplatform vir deurlopende inspeksie en kodekwaliteitmeting.
Ondersteun kode-analise en foutopsporing volgens die reëls van die MISRA C, MISRA C++, MITER/CWE en CERT Secure Coding Standards-programmeringstandaarde. Dit kan ook foute uit die OWASP Top 10 en CWE/SANS Top 25 programmeerfoutlyste herken.
Ten spyte van die feit dat die platform verskeie gereedgemaakte gereedskap gebruik, verminder SonarQube die resultate tot 'n enkele dashboard, hou 'n geskiedenis van lopies en laat jou sodoende die algemene neiging van veranderinge in sagtewarekwaliteit tydens ontwikkeling sien.

Meer besonderhede kan gevind word by amptelike webwerf

'n Groot aantal programmeertale word ondersteun. Te oordeel aan die inligting vanaf die skakel hierbo, is dit meer as 25 tale. Om 'n spesifieke taal te ondersteun, moet jy die toepaslike inprop installeer. Die gemeenskapsweergawe bevat 'n inprop om mee te werk Javascript (insluitend tipes skrif), hoewel die wiki die teenoorgestelde sê. Agter Javascript plugin antwoorde SonarJS, vir Typescript SonarTS onderskeidelik.

Die amptelike kliënt word gebruik om dekkinginligting te stuur sonarqube-skandeerder, wat, met behulp van die instellings van config-lêer, stuur hierdie data na die bediener klankQube vir verdere konsolidasie en samevoeging.

Vir Javascript daar is npm omhulsel. Dus, kom ons begin stap-vir-stap implementering klankQube в Vue-projek gebruik Tikskrif.

Om die bediener te ontplooi klankQube laat ons voordeel trek Docker-komponeer.

sonar.yaml:

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

Begin:

docker-compose -f sonar.yml up

Daarna klankQube sal beskikbaar wees by: http://localhost:9001 .

Daar is nog geen projekte daarin nie en dit is regverdig. Ons sal hierdie situasie regstel. Ek het die amptelike voorbeeldprojek vir VueJS+TS+Jest. Kom ons buig dit na onsself:

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

Eerstens moet ons die kliënt installeer klankQube, wat genoem word sonar-skandeerdervir NPM daar is 'n omhulsel:

yarn add sonarqube-scanner

En voeg dadelik die opdrag by skrifte om daarmee te werk.

package.json:

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

Volgende, vir die skandeerder om te werk, moet jy die projekinstellings in 'n spesiale lêer instel. Kom ons begin met die basiese beginsels.

sonar-projek.eienskappe:

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 - adres sonar'A;
sonar.projekSleutel - unieke projek identifiseerder op die bediener sonar'A;
sonar.projekNaam – sy naam, dit kan enige tyd verander word, aangesien die projek geïdentifiseer word deur projeksleutel;
sonar.bronne – gids met bronne, gewoonlik dit src, maar kan enigiets wees. Hierdie vouer is relatief tot die wortelgids gestel, wat die vouer is waaruit die skandeerder geloods word;
sonar.toetse – 'n parameter wat in tandem met die vorige een gaan. Dit is die gids waar die toetse geleë is. In hierdie projek is daar nie so 'n gids nie, en die toets is langs die komponent wat getoets word in die gids 'toets', so ons sal dit vir eers ignoreer en die volgende parameter gebruik;
sonar.toets.insluitings – pad vir toetse met behulp van 'n masker, daar kan verskeie elemente gelys wees geskei deur kommas;
sonar.sourceEncoding - enkodering vir bronlêers.

Vir die eerste bekendstelling van die skandeerder is alles gereed, behalwe vir die belangrikste voorafgaande aksie: die lansering van die toetsenjin self, sodat dit inligting kan genereer oor die dekking, wat die skandeerder daarna sal gebruik.

Maar om dit te doen, moet jy die toetsenjin instel om hierdie inligting te genereer. In hierdie projek is die toetsenjin daar is. En sy instellings is in die ooreenstemmende afdeling van die lêer pakket.json.

Kom ons voeg hierdie instellings by:

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

Dit wil sê, ons stel die vlag self vir die behoefte om dekking te bereken en die bron (saam met uitsonderings) op grond waarvan dit gevorm sal word.

Laat ons nou die toets uitvoer:

yarn test

Ons sal die volgende sien:

Die rede is dat daar geen kode in die komponent self is nie. Kom ons maak dit reg.

HelloWorld.vue:

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

Dit sal genoeg wees om dekking te bereken.

Nadat ons die toets herbegin het, sal ons hiervan seker maak:

Op die skerm behoort ons inligting oor die dekking te sien, en 'n gids sal in die projekgids geskep word dekking met inligting oor toetsdekking in 'n universele formaat LCOV (LTP GCOV uitbreiding).

Gcov is 'n vrylik verspreide hulpprogram om kodedekking te ondersoek. Gcov genereer die presiese aantal uitvoerings vir elke stelling in 'n program en laat jou toe om aantekeninge by die bronkode te voeg. Gcov kom as 'n standaardhulpmiddel as deel van die GCC-pakket.
Lcov - grafiese koppelvlak vir gcov. Dit stel gcov-lêers saam vir veelvuldige bronlêers en produseer 'n stel HTML-bladsye met kode en dekkinginligting. Bladsye word ook gegenereer om navigasie makliker te maak. Lcov ondersteun dekking van snare, funksies en takke.

Nadat die toetse voltooi is, sal dekkingsinligting in gevind word coverage/lcov.info.
Ons moet sê sonar'Waar kan ek dit vandaan kry? Laat ons dus die volgende reëls by die konfigurasielêer voeg. Maar daar is een punt: projekte kan veeltalig wees, dit wil sê in die gids src daar is bronkodes vir verskeie programmeertale en affiliasie met een of ander, en op sy beurt word die gebruik van een of ander inprop bepaal deur die uitbreiding daarvan. En dekkinginligting kan op verskillende plekke vir verskillende programmeertale gestoor word, so elke taal het sy eie afdeling om dit op te stel. Ons projek gebruik Tikskrif, so ons benodig 'n instellingsafdeling net daarvoor:

sonar-projek.eienskappe:

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

Alles is gereed vir die eerste bekendstelling van die skandeerder. Ek wil daarop let dat die projek is sonar'e word outomaties geskep die eerste keer dat jy die skandeerder vir 'n gegewe projek laat loop. In daaropvolgende tye sal inligting opgehoop word om die dinamika van veranderinge in projekparameters oor tyd te sien.

Dus, kom ons gebruik die opdrag wat vroeër geskep is pakket.json:

yarn run sonar

Let wel: jy kan ook die parameter gebruik -X vir meer gedetailleerde logging.

As die skandeerder vir die eerste keer geloods is, sal die binêre van die skandeerder self eers afgelaai word. Daarna begin dit en begin die bediener skandeer sonar'a vir geïnstalleerde inproppe, waardeur ondersteunde taal bereken word. Verskeie ander parameters vir die werking daarvan word ook gelaai: kwaliteit profiele, aktiewe reëls, metrieke bewaarplek, bedienerreëls.

Let wel: Ons sal nie in detail daaroor stilstaan binne die raamwerk van hierdie artikel nie, maar u kan altyd amptelike bronne kontak.

Vervolgens begin die gidsontleding src vir die beskikbaarheid van bronlêers vir alle (as 'n spesifieke een nie uitdruklik gespesifiseer word nie) ondersteunde taal, met die daaropvolgende indeksering.

Vervolgens kom verskeie ander ontledings, waarop ons nie in hierdie artikel fokus nie (byvoorbeeld, soos linting, opsporing van kodeduplisering, ens.).

Heel aan die einde van die skandeerder se werk word alle versamelde inligting saamgevoeg, geargiveer en na die bediener gestuur.

Hierna kan ons reeds sien wat in die webkoppelvlak gebeur het:

Soos ons kan sien, het iets gewerk, en toon selfs 'n soort dekking, maar dit stem nie ooreen met ons s'n nie daar is- rapporteer.

Kom ons vind dit uit. Kom ons kyk in meer besonderhede na die projek, klik op die dekkingswaarde en "val deur" in 'n gedetailleerde lêerverslag:

Hier sien ons, benewens die hoof, ondersoekde lêer HelloWorld.vue, daar is ook 'n lêer hoof.ts, wat die hele prentjie van die dekking bederf. Maar hoekom het ons dit uitgesluit by die berekening van dekking. Ja, alles is reg, maar dit was op die vlak daar is, maar die skandeerder het dit geïndekseer, so dit het in sy berekeninge beland.

Kom ons maak dit reg:

sonar-projek.eienskappe:

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

Ek wil graag 'n verduideliking maak: benewens die dopgehou wat in hierdie parameter gespesifiseer word, word alle dopgehou wat in die parameter gelys word ook bygevoeg sonar.toets.insluitings.

Nadat ons die skandeerder begin het, sien ons die korrekte inligting:

Kom ons kyk na die volgende punt - Kwaliteit profiele. Ek het hierbo oor ondersteuning gepraat sonarvan verskeie tale op dieselfde tyd. Dit is presies wat ons sien. Maar ons weet dat ons projek ingeskryf is TS, so hoekom beur die skandeerder met onnodige manipulasies en kontroles. Ons sal die taal vir analise stel deur nog een parameter by die konfigurasielêer by te voeg sonar'A:

sonar-projek.eienskappe:

...
sonar.language=ts
...

Kom ons laat die skandeerder weer hardloop en sien die resultaat:

Die dekking was heeltemal weg.

As ons na die skandeerderlogboek kyk, kan ons die volgende reël sien:

Dit wil sê, ons projeklêers is eenvoudig nie geïndekseer nie.

Die situasie is soos volg: amptelik ondersteun VueJs is in die inprop SonarJSvir wie verantwoordelik is Javascript.

Maar hierdie ondersteuning is nie in die inprop nie SonarTS vir TS, waaroor 'n amptelike kaartjie in die foutspoorder oopgemaak is sonar'A:

Hier is 'n paar antwoorde van een van die verteenwoordigers van die SonarQube-ontwikkelaars, wat hierdie feit bevestig.

Maar alles het vir ons gewerk, maak jy beswaar. Ja dit is, kom ons probeer dit 'n bietjie "hack".
As daar ondersteuning is .vue-lêers sonar'O, kom ons probeer dan vir hom sê om hulle as te beskou Tikskrif.

Kom ons voeg 'n parameter by:

sonar-projek.eienskappe:

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

Kom ons begin die skandeerder:

En, voila, alles is terug na normaal, en met net een profiel vir Tikskrif. Dit wil sê, ons het daarin geslaag om die probleem ter ondersteuning op te los VueJs+TS vir klankQube.

Kom ons probeer verder gaan en die dekkingsinligting 'n bietjie verbeter.

Wat ons tot dusver gedoen het:

by die projek gevoeg sonar-skandeerder;
stel op daar is om dekkingsinligting te genereer;
gekonfigureer sonar-skandeerder;
het die ondersteuningsprobleem opgelos .vue-lêers + Tikskrif.

Benewens toetsdekking is daar ander interessante nuttige kriteria vir kodekwaliteit, byvoorbeeld kodeduplisering en die aantal reëls (wat betrokke is by die berekening van koëffisiënte wat verband hou met kodekompleksiteit) van die projek.

In die huidige implementering van die inprop om mee te werk TS (SonarTS) sal nie werk nie CPD (Kopieer Plak Detector) en tel reëls kode .vue-lêers.

Om 'n sintetiese situasie van kodeduplisering te skep, dupliseer eenvoudig die komponentlêer met 'n ander naam en voeg dit ook by die kode hoof.ts 'n dummy-funksie en dupliseer dit met 'n ander naam. Om te kyk vir duplisering soos in .vue, en in .ts -lêers.

hoof.ts:

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

Om dit te doen, moet jy tydelik kommentaar lewer op die konfigurasielyn:

sonar-projek.eienskappe:

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

Kom ons herbegin die skandeerder saam met die toets:

yarn test && yarn run sonar

Natuurlik sal ons dekking val, maar nou stel ons nie daarin belang nie.

In terme van die duplisering van reëls kode, sal ons sien:

Om te kontroleer sal ons gebruik CPD-nut - jscpd:

npx jscpd src

Vir reëls kode:

Miskien sal dit in toekomstige inpropweergawes opgelos word SonarJS(TS). Ek wil daarop let dat hulle geleidelik begin om hierdie twee inproppe in een saam te voeg SonarJS, wat ek dink korrek is.

Nou wou ek die opsie oorweeg om dekkinginligting te verbeter.

Tot dusver kan ons toetsdekking in persentasie vir die hele projek sien, en vir lêers in die besonder. Maar dit is moontlik om hierdie aanwyser uit te brei met inligting oor die hoeveelheid eenheid-toetse vir die projek, sowel as in die konteks van lêers.

Daar is 'n biblioteek wat kan daar is-skakel die verslag om in formaat vir sonar'A:
generiese toetsdata - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Kom ons installeer hierdie biblioteek in ons projek:

yarn add jest-sonar-reporter

En voeg dit by die konfigurasie daar is:

package.json:

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

Laat ons nou die toets uitvoer:

yarn test

Daarna sal 'n lêer in die wortel van die projek geskep word toets-verslag.xml.

Kom ons gebruik dit in die konfigurasie sonar'A:

sonar-projek.eienskappe:

…
sonar.testExecutionReportPaths=test-report.xml
…

En herbegin die skandeerder:

yarn run sonar

Kom ons kyk wat het verander in die koppelvlak sonar'A:

En niks het verander nie. Die feit is dat Sonar nie die lêers wat in die Jest-verslag beskryf word, as lêers beskou nie eenheid-toetse. Om hierdie situasie reg te stel, gebruik ons die konfigurasieparameter sonar sonar.toetse, waarin ons die dopgehou met toetse uitdruklik sal aandui (ons het vir eers net een):

sonar-projek.eienskappe:

…
sonar.tests=src/components/__tests__
…

Kom ons herbegin die skandeerder:

yarn run sonar

Kom ons kyk wat het verander in die koppelvlak:

Nou het ons die nommer van ons gesien eenheid-toetse en, nadat ons misluk het deur binne te klik, kan ons die verspreiding van hierdie nommer onder die projeklêers sien:

Gevolgtrekking

Dus, ons het gekyk na 'n instrument vir deurlopende analise klankQube. Ons het 'n projek suksesvol daarin geïntegreer VueJs+TS. Sommige versoenbaarheidsprobleme opgelos. Ons het die inligtinginhoud van die toetsdekkingsaanwyser verhoog. In hierdie artikel het ons slegs een van die kodekwaliteitskriteria ondersoek (miskien een van die belangrikstes), maar klankQube ondersteun ander kwaliteitskriteria, insluitend veiligheidstoetsing. Maar nie al hierdie kenmerke is ten volle beskikbaar in gemeenskap-weergawes. Een van die interessante en nuttige kenmerke is integrasie klankQube met verskeie kodebewaarplekbestuurstelsels, soos GitLab en BitBucket. Om te verhoed samesmelt trek (samevoeg) versoek'a na die hooftak van die bewaarplek wanneer die dekking verswak word. Maar hierdie is 'n storie vir 'n heeltemal ander artikel.

PS: Alles wat in die artikel beskryf word in die vorm van kode is beskikbaar in my vurk.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Gebruik jy die SonarQube-platform:

26,3%Ja 5
15,8%No3
15,8%Ek het van hierdie platform gehoor en wil 3 gebruik
10,5%Ek het van hierdie platform gehoor en wil nie gebruik nie2
0,0%Ek gebruik 'n ander platform0
31,6%Eerste keer wat ek van haar hoor6

19 gebruikers het gestem. 3 gebruikers het buite stemming gebly.

Bron: will.com

VueJS+TS-projekintegrasie met SonarQube

Gevolgtrekking

Gebruik jy die SonarQube-platform:

Voeg 'n opmerking Kanselleer antwoord