I vårt arbete använder vi aktivt plattformen SonarQube för att upprätthålla en hög kodkvalitet. Vid integrationen av ett av projekten skrivet i VueJs+Typescript, uppstod problem. Därför skulle jag vilja berätta mer om hur vi lyckades lösa dem.

Denna artikel handlar, som jag nämnde tidigare, om plattformen SonarQube. Lite teori – vad är det alls för något, för de som hör talas om den för första gången:

SonarQube (tidigare Sonar) – en plattform med öppen källkod för kontinuerlig analys och bedömning av kodkvalitet.
Stöder kodanalys och felidentifiering enligt programmeringsstandarder som MISRA C, MISRA C++, MITRE/CWE och CERT Secure Coding Standards. Det kan också identifiera fel från OWASP Top 10 och CWE/SANS Top 25 programvarufel.
Trots att plattformen använder olika färdiga verktyg, sammanfattar SonarQube resultaten till en enhetlig instrumentpanel, vilket visar historiken av körningar och därigenom möjliggör att se den övergripande trenden i förändringen av programvarukvalitet under utvecklingen.

Mer information kan erhållas på den officiella webbplatsen

Det stöder ett stort antal programmeringsspråk. Enligt informationen från länken ovan — det är över 25 språk. För att stödja ett specifikt språk måste motsvarande plugin installeras. I community-versionen ingår pluginet för arbete med Javascript (inklusive typesсript), även om det står motsatsen i wikin. Det Javascript sköts av pluginet SonarJS, för Typescript SonarTS respektive.

För att skicka täckningsinformation används den officiella klienten sonarqube-scanner, som, med inställningar från config-filen, skickar dessa data till servern SonarQube för vidare konsolidering och aggregating.

För Javascript det finns npm-wrapper. Så, vi börjar med steg-för-steg implementeringen av SonarQube på Vue-projektet som använder Typescript.

För att sätta upp servern SonarQube använder vi docker-compose.

sonar.yaml:

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

Starta:

docker-compose -f sonar.yml up

Efter detta SonarQube kommer att vara tillgängligt på adressen – http://localhost:9001 .

Just nu finns det inga projekt, och det är förståeligt. Vi kommer att åtgärda denna situation. Jag utgick från det officiella exempelprojektet för VueJS+TS+Jest. Vi klonar det till oss:

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

Först behöver vi installera klienten SonarQube, som kallas sonar-scanner, för npm finns en wrapper:

yarn add sonarqube-scanner

Och vi lägger omedelbart till kommandot i scripts för att arbeta med det.

package.json:

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

Därefter, för att skannern ska fungera, måste vi ange projektinställningar i en speciell fil. Låt oss börja med det grundläggande.

sonar-project.properties:

sonar.host.url=http://localhost:9001

sonar.projectKey=test-project-vuejs-ts
sonar.projectName=Test-applikation (VueJS+TS)

sonar.sources=src
# sonar.tests=
sonar.test.inclusions=src/**/*tests*/**
sonar.sourceEncoding=UTF-8

sonar.host.url – adressen Sonar’a;
sonar.projectKey – en unik identifierare för projektet på servern Sonar’a;
sonar.projectName – namnet på det, vilket kan ändras när som helst, eftersom identifieringen av projektet sker genom projectKey;
sonar.sources – mappen med källor, vanligtvis är detta src, men det kan vara vad som helst. Denna mapp anges relativt rotmappen, vilket är mappen från vilken skannern körs;
sonar.tests – en parameter som går i par med den föregående. Detta är mappen där testerna finns. I detta projekt finns det ingen sådan mapp, utan testet ligger bredvid den testade komponenten i mappen 'test‘, så vi kommer tills vidare att ignorera den och använda nästa parameter;
sonar.test.inclusions – sökvägen för tester med en mask, det kan finnas flera element listade genom kommatecken;
sonar.sourceEncoding – kodningen för källfilerna.

För den första körningen av skannern är allt klart, förutom den grundläggande föregående åtgärden: att köra själva testmotorn för att generera information om täckning som skannern senare ska använda.

Men för detta måste testmotorn konfigureras för att generera denna information. I detta projekt är testmotorn Jest. Och dess inställningar finns i den relevanta delen av filen package.json.

Vi lägger till dessa inställningar:

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

Det vill säga vi ställer in flaggan för behovet av att beräkna täckningen och källan (tillsammans med undantagen) baserat på vilka den ska bildas.

Nu kör vi testet:

yarn test

Vi får följande resultat:

Anledningen är att det inte finns någon kod i själva komponenten. Låt oss åtgärda detta.

HelloWorld.vue:

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

Detta bör räcka för att beräkna täckningen.

Efter omstart av testet kan vi bekräfta detta:

På skärmen ska vi se information om täckning, och i projektmappen kommer en mapp att skapas coverage med information om testtäckning i ett universellt format LCOV (LTP GCOV-extension).

Gcov — ett fritt tillgängligt verktyg för att undersöka kodtäckning. Gcov genererar det exakta antalet körningar för varje uttalande i programmet och möjliggör att lägga till anteckningar i källkoden. Gcov levereras som ett standardverktyg i GCC-paketet.
Lcov — ett grafiskt gränssnitt för gcov. Det samlar gcov-filer för flera källkods-filer och skapar ett komplettpaket av HTML-sidor med kod och detaljer om täckning. Sidor genereras också för att förenkla navigeringen. Lcov stöder täckning av rader, funktioner och förgreningar.

Efter att testerna har körts kommer informationen om täckning att finnas i coverage/lcov.info.
Vi måste ange Sonarvarifrån vi ska hämta den. Därför lägger vi till följande rader i dess konfigurationsfil. Men det finns en sak: projekt kan vara flerspråkiga, det vill säga i mappen src finns källkod för flera programmeringsspråk och tillhörighet till respektive språk, och i sin tur bestäms användningen av en viss plugin, baserat på dess filändelse. Och informationen om täckning kan lagras på olika ställen för olika programmeringsspråk, så för varje programmeringsspråk finns det en egen konfigurationsdel för detta. Vårt projekt använder Typescript, så vi behöver en konfigurationsdel just för det:

sonar-project.properties:

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

Allt är klart för första körningen av skannern. Jag vill påpeka att projektet i Sonarskapades automatiskt vid första körningen av skannern för detta projekt. Vid efterföljande tillfällen kommer informationen redan att ackumuleras, så att man kan se hur projektparameterna förändras över tid.

Så, låt oss använda kommandot som tidigare skapades i package.json:

yarn run sonar

Anmärkning: man kan också använda parametern -X för mer detaljerad loggning.

Om skannern kördes för första gången kommer dess binärfil att laddas ner först. Därefter startas den och börjar skanna servern Sonarefter installerade plugins, vilket beräknar de stödda programmeringsspråken. Andra olika parametrar för dess drift laddas också: quality profiles, active rules, metrics repository, server rules.

Anmärkning: kommer vi inte att gå in i detaljer om i denna artikel, men man kan alltid hänvisa till officiella källor.

Därefter inleds analysen av mappen src avseende på förekomsten av källfiler för alla (om inget specifikt anges) stödda programmeringsspråk, följt av deras indexering.

Därefter följer olika analyser som vi inte fokuserar på i denna artikel (till exempel som: linting, identifiering av koddupplikationer osv.).

I slutet av skanningsprocessen sker en aggregering av all insamlad information, komprimering och skickas till servern.

Efter detta kan vi titta på vad som har uppnåtts i webgränssnittet:

Som vi ser har något blivit resultat, och visar till och med en viss täckning, men det motsvarar inte vår Jest-rapport.

Låt oss fördjupa oss i detta. Vi tittar närmare på projektet, klickar på täckningsvärdet och "dyker ner" i den detaljerade rapporten om filerna:

Här ser vi förutom den huvudsakliga, undersökta filen HelloWorld.vue, finns även en fil main.ts, som förstör hela bilden av täckningen. Men hur kan det vara så, vi uteslöt honom från täckningsberäkningen. Ja, det stämmer, men det var på nivå Jest, men skannern har indexerat honom, så han kom med i beräkningarna.

Låt oss fixa detta:

sonar-project.properties:

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

Jag vill förtydliga: förutom de mappar som anges i denna parameter, inkluderas också alla mappar som listas i parametern sonar.test.inclusions.

Efter att skannern har kört ser vi redan korrekt information:

Låt oss diskutera nästa punkt – Kvalitetsprofiler. Jag nämnde tidigare stödet för Sonarflera programmeringsspråk samtidigt. Detta är precis vad vi observerar. Men vi vet att projektet är skrivet i TS, så varför belasta skannern med onödiga manipulationer och kontroller. Språket för analys ställs in genom att lägga till ytterligare en parameter i konfigurationsfilen Sonar:

sonar-project.properties:

...
sonar.language=ts
...

Låt oss köra skannern igen och se resultatet:

Täckningen har försvunnit helt.

Om vi tittar i skannerloggarna kan vi se följande rad:

Det vill säga att våra projektfiler helt enkelt inte har indexerats.

Situationen är som följer: officiellt stöd för VueJs finns i pluginet SonarJS, som ansvarar för Javascript.

Men detta stöd finns inte i pluginet SonarTS för TS, vilket bekräftas av en officiell biljett i bugghanteraren. Sonar:

Här är några svar från en av representanter från SonarQube-utvecklarna, som bekräftar detta faktum.

Men det fungerade ju tidigare, invänder du. Ja, det är helt riktigt, låt oss försöka lite “hacka”.
Om det finns stöd för .vue-filer. SonarSå låt oss försöka säga till honom att han ska se dem som Typescript.

Låt oss lägga till en parameter:

sonar-project.properties:

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

Låt oss köra skannern:

Och vips, allt har återgått till det normala, med endast en profil för Typescript. Så vi lyckades lösa problemet med stödet för VueJs+TS för SonarQube.

Låt oss gå vidare och förbättra informationen om täckning.

Vad har vi gjort hittills:

lagt till i projektet Sonar-skannern;
konfigurerat Jest för att generera information om täckning;
konfigurerat Sonar-skannern;
löste problemet med stödet för .vue-filer + Typescript.

Utöver testtäckning finns det andra intressanta och användbara kodkvalitetskriterier, exempelvis kodduplicering och antal rader (deltar i beräkningen av koefficienter relaterade till kodens komplexitet) i projektet.

I den nuvarande implementationen av plugin för att arbeta med TS (SonarTS) kommer inte att fungera CPD (Copy Paste Detector) och antal rader kod .vue-filer.

För att skapa en syntetisk situation för kodduplicering, duplicera helt enkelt komponentfilen med ett annat namn, lägg även till en tom funktion i koden och duplicera den med ett annat namn. För att kontrollera dupliceringen som i main.ts , samt i .vue.ts -filer. main.ts:

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

För detta måste vi temporärt kommentera konfigurationsraden:

Låt oss starta om skannern tillsammans med testningen:

sonar-project.properties:

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

yarn test && yarn run sonar

Självklart kommer vår täckning att sjunka, men det är inte så intressant just nu.

I relation till kodduplication kommer vi att se:

För att verifiera använder vi

CPD -verktyget –jscpd npx jscpd src:

För rader kod:

Detta kan komma att lösas i framtida versioner av pluginerna

SonarJS(TS) . Jag vill påpeka att de gradvis börjar slå samman dessa två plugins till ett, vilket jag tror är rätt. SonarJSNu skulle jag vilja överväga möjligheten att förbättra informationen om täckning.

För närvarande ser vi testtäckningen i procent, över hela projektet, och per filer specifikt. Men det finns en möjlighet att utöka detta mått med information om antalet

unit -tester i projektet, samt i relation till filer.Det finns ett bibliotek som kan

-rapport konvertera till format för Jestgeneric test data Sonar:
Låt oss installera detta bibliotek i vårt projekt: — https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

yarn add jest-sonar-reporter

Och lägg till det i konfigurationen

... "testResultsProcessor": "jest-sonar-reporter" ... Jest:

package.json:

Nu utför vi testet:

Efter det kommer en fil att skapas i projektets rot

yarn test

test-report.xml Låt oss använda den i konfigurationen.

... sonar.testExecutionReportPaths=test-report.xml ... Sonar:

sonar-project.properties:

Och starta om skannern:

Och vi startar om skannern:

yarn run sonar

Låt oss se vad som har ändrats i gränssnittet Sonar:

Och ingenting har ändrats. Det är så att Sonar inte betraktar filerna som beskrivs i Jest-rapporten som filer -tester i projektet, samt i relation till filer.-test. För att rätta till denna situation använder vi en konfigurationsparameter Sonar sonar.tests, där vi tydligt anger mapparna med test (vi har för närvarande bara en):

sonar-project.properties:

…
sonar.tests=src/components/__tests__
…

Låt oss starta om skannern:

yarn run sonar

Låt oss se vad som har ändrats i gränssnittet:

Nu har vi sett antalet av våra -tester i projektet, samt i relation till filer.-test och genom att klicka in kan vi se fördelningen av detta antal över projektfilerna:

Slutsats

Så vi har gått igenom verktyget för kontinuerlig analys SonarQube. Vi har framgångsrikt integrerat det med ett projekt skrivet i VueJs+TS. Vi har löst vissa kompatibilitetsproblem. Vi har ökat informationsinnehållet i testtäckningsmåttet. I den här artikeln har vi bara gått igenom ett av kvalitetskriterierna (möjligen ett av de viktigaste), men SonarQube stödjer även andra kvalitetskriterier, inklusive säkerhetstestning. Men inte alla dessa funktioner är helt tillgängliga i community-versionen. En av de intressanta och användbara funktionerna är integrationer SonarQube med olika källkodshanteringssystem, till exempel GitLab och BitBucket. För att förhindra merge pull(merge) requesttill huvudgrenen av förrådet vid en reduktion av täckningen. Men det är historien för en helt annan artikel.

PS: Allt som beskrivs i artikeln som kod finns tillgängligt i min fork.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.