In ons werk maken we actief gebruik van het platform SonarQube om de codekwaliteit op een hoog niveau te houden. Bij de integratie van een van de projecten, geschreven in VueJs+Typescript, deden zich problemen voor. Daarom wil ik graag meer vertellen over hoe we deze hebben opgelost.
In dit artikel gaat het, zoals ik eerder zei, over het platform SonarQube. Een korte uitleg — wat is het eigenlijk, voor degenen die er voor het eerst van horen:
SonarQube (voorheen Sonar) — een open source platform voor continue analyse en meting van codekwaliteit.
Het ondersteunt code-analyse en het zoeken naar fouten volgens de normen van de programmeerstandaarden MISRA C, MISRA C++, MITRE/CWE en CERT Secure Coding Standards. Daarnaast kan het fouten herkennen vanuit de OWASP Top-10 en CWE/SANS Top-25 programmeerfoutenlijsten.
Ondanks dat het platform verschillende kant-en-klare tools gebruikt, brengt SonarQube de resultaten samen in één informatiepaneel, waardoor de geschiedenis van uitvoeringen wordt vastgelegd en je zo de algemene trend in de kwaliteit van de softwareontwikkeling kunt zien.
Meer informatie is te vinden op
Er worden veel programmeertalen ondersteund. Volgens de informatie op de bovenstaande link zijn dit er meer dan 25. Om ondersteuning voor een specifieke taal te krijgen, is het nodig om de bijbehorende plug-in te installeren. In de community-versie zit een plug-in voor het werken met Javascript (inclusief typesсript), hoewel in de wiki het tegenovergestelde is vermeld. Hiervoor is verantwoordelijk de plug-in Javascript SonarJS , en voor TypescriptSonarTS Om informatie over de dekking te verzenden, gebruiken we de officiële client respectievelijk.
sonarqube-scanner , die, gebruikmakend van de instellingen uitconfig -bestand, deze gegevens naar de server verzendtvoor verdere consolidatie en aggregatie. SonarQube npm-wrapper
Voor Javascript bestaande Typescript SonarQube in Vuegebruikt. Voor het opzetten van de server.
maken we gebruik van SonarQube sonar.yaml docker-compose.
version: '1' services: simplesample-sonar: image: sonarqube:lts ports: - 9001:9000 - 9092:9092 network_mode: bridge:
docker-compose -f sonar.yml upRun:
Na ditis toegankelijk op het adres – SonarQube Vooralsnog zijn er geen projecten in, en dat is terecht. We gaan deze situatie verbeteren. Als basis heb ik het officiële voorbeeldproject voor .
VueJS+TS+Jest . Laten we het klonen:git clone https://github.com/vuejs/vue-test-utils-typescript-example.git
Eerst moeten we de client installeren,die heet SonarQubesonar-scanner , vooris er een wrapper: npm yarn add sonarqube-scanner
En laten we meteen een commando toevoegen invoor het werken met hem. scripts voor het werken ermee.
package.json:
{
…
scripts: {
...
"sonar": "sonar-scanner"
...
},
…
}Vervolgens moet je de projectinstellingen opgeven in een speciaal bestand voor de scanner. Laten we beginnen met de basisinstellingen.
sonar-project.properties:
sonar.host.url=http://localhost:9001
sonar.projectKey=test-project-vuejs-ts
sonar.projectName=Test Applicatie (VueJS+TS)
sonar.sources=src
# sonar.tests=
sonar.test.inclusions=src/**/*tests*/**
sonar.sourceEncoding=UTF-8- sonar.host.url – adres Sonar’a;
- sonar.projectKey – unieke identificatie van het project op de server Sonar’a;
- sonar.projectName – de naam ervan, deze kan op elk moment worden gewijzigd, aangezien identificatie van het project gebeurt op basis van projectKey;
- sonar.sources – de map met de bronteksten, meestal is dit src, maar kan van alles zijn. Deze map wordt gedefinieerd ten opzichte van de rootmap, die de map is van waaruit de scanner is gestart;
- sonar.tests – parameter die samen met de vorige komt. Dit is de map waar de tests zich bevinden. In dit project is er geen dergelijke map, en ligt de test naast de te testen component in de map ‘test‘, daarom negeren we deze voorlopig en maken we gebruik van de volgende parameter;
- sonar.test.inclusions – pad voor tests met gebruik van een patroon, er kunnen meerdere elementen worden vermeld, gescheiden door komma's;
- sonar.sourceEncoding – codering voor de bronbestanden.
Voor de eerste запуск van de scanner is alles klaar, behalve de belangrijkste voorafgaande actie: het starten van de testengine, om informatie over de dekking te genereren, die de scanner later zal gebruiken.
Maar hiervoor moet de testengine worden ingesteld om deze informatie te genereren. In dit project is de testengine Jest. En de instellingen ervan bevinden zich in het desbetreffende gedeelte van het bestand. package.json.
Laten we deze instellingen toevoegen:
"collectCoverage": true,
"collectCoverageFrom": [
"src/**/*",
"!src/main.ts",
"!src/App.vue",
"!src/**/*.d.*",
"!src/**/*__tests__*"
],Dit betekent dat we de vlag voor de noodzaak van het berekenen van de dekking en de source (samen met de uitzonderingen) opgeven, waarop de dekking zal worden gebaseerd.
Laten we nu de test uitvoeren:
yarn testWe zullen het volgende zien:
De reden is dat er geen code in de component zelf is. Laten we dit verhelpen.
HelloWorld.vue:
...
methods: {
calc(n) {
return n + 1;
}
},
mounted() {
this.msg1 = this.msg + this.calc(1);
},
...Dit zal genoeg zijn om de dekking te berekenen.
Na het opnieuw starten van de test zullen we dit verifiëren:
Op het scherm moeten we informatie over de dekking zien, en in de projectmap zal een map worden aangemaakt coverage met informatie over de dekking van de tests in een universeel formaat LCOV (LTP GCOV-extensie).
Gcov Een vrij beschikbare tool voor het onderzoeken van code-dekking. Gcov genereert het exacte aantal uitvoeringen voor elke operator in het programma en stelt u in staat om annotaties aan de broncode toe te voegen. Gcov wordt geleverd als een standaardtool als onderdeel van het GCC-pakket.
Lcov Een grafische interface voor gcov. Het verzamelt gcov-bestanden voor meerdere bestanden met broncode en creëert een set HTML-pagina's met code en informatie over dekking. Ook worden pagina's gegenereerd voor vereenvoudigde navigatie. Lcov ondersteunt dekking van regels, functies en vertakkingen.
Na het uitvoeren van tests zal de informatie over dekking zich bevinden in coverage/lcov.info.
We moeten aangeven Sonarwaar het vandaan gehaald moet worden. Daarom voegen we de volgende regels toe aan zijn configuratiebestand. Maar er is één punt: projecten kunnen meertalige zijn, dat wil zeggen dat in de map src de bronnen voor meerdere programmeertalen zich bevinden en de toewijzing aan de ene of andere taal, en het gebruik van de ene of andere plugin, wordt bepaald door de extensie. En de informatie over dekking kan op verschillende plaatsen worden opgeslagen voor verschillende programmeertalen, daarom is er voor elke programmeertaal een eigen sectie voor de configuratie hiervan. Ons project gebruikt Voor het opzetten van de server, daarom hebben we een configuratiesectie specifiek voor hem nodig:
sonar-project.properties:
sonar.typescript.coveragePlugin=lcov
sonar.typescript.lcov.reportPaths=coverage/lcov.infoAlles is klaar voor de eerste scan van de scanner. Ik wil opmerken dat het project in Sonarautomatisch wordt aangemaakt bij de eerste scan van de scanner voor dit project. Bij volgende keren zal de informatie al worden geaccumuleerd om de dynamiek van wijziging van projectparameters in de tijd te zien.
Dus, laten we de eerder gemaakte opdracht gebruiken in package.json:
yarn run sonar Opmerking: u kunt ook de parameter gebruiken -X voor meer gedetailleerde logging.
Als de scanner voor het eerst wordt gestart, wordt eerst de binaire uitvoeringsbestanden van de scanner gedownload. Daarna wordt deze gestart en begint deze de server Sonarte scannen op geïnstalleerde plugins, waarbij de ondersteunde programmeertalen worden berekend. Ook worden verschillende andere parameters gedownload voor het functioneren: quality profiles, active rules, metrics repository, server rules.
Opmerking: we zullen hier niet in detail op ingaan binnen het kader van dit artikel, maar het is altijd mogelijk om de officiële bronnen te raadplegen.
Daarna begint de analyse van de map src over de aanwezigheid van bronbestanden voor alle ondersteunde programmeertalen (tenzij specifiek een bepaalde taal is opgegeven), gevolgd door indexering.
Daarna volgen andere verschillende analyses waarop we in dit artikel niet ingaan (bijvoorbeeld: linting, het identificeren van code duplicatie, enz.).
Aan het einde van de scannerwerkzaamheden worden alle verzamelde informatie geaggregeerd, gearchiveerd en naar de server gestuurd.
Daarna kunnen we bekijken wat we in de webinterface hebben gekregen:
Zoals we zien, is er iets verkregen, en het toont zelfs een bepaalde dekking, maar die komt niet overeen met ons Jest-rapport.
Laten we dit bekijken. Laten we het project gedetailleerd bekijken, klikken op de dekkingswaarde, en "dieper duiken" in het gedetailleerde rapport per bestand:
Hier zien we naast het hoofdonderzochte bestand HelloWorld.vue, is er ook een bestand main.ts, dat de hele dekking verpest. Maar hoe kan dat, we hebben het uitgesloten van de dekking. Ja, dat klopt, maar dat was op niveau Jest, maar de scanner heeft het geïndexeerd, dus het is meegenomen in zijn berekeningen.
Laten we dit oplossen:
sonar-project.properties:
...
sonar.exclusions=src/main.ts
...Ik wil een opmerking maken: naast de mappen die in deze parameter zijn opgegeven, worden ook alle mappen toegevoegd die zijn vermeld in de parameter sonar.test.inclusions.
Na het starten van de scanner zien we al correcte informatie:
Laten we de volgende kwestie bekijken - Quality profiles. Ik heb hierboven gesproken over de ondersteuning voor meerdere programmeertalen tegelijkertijd. Dit is precies wat we waarnemen. Maar we weten dat ons project is geschreven in Sonar, dus waarom de scanner extra manipulaties en controles laten uitvoeren. De taal voor analyse stellen we in door een extra parameter aan het configuratiebestand toe te voegen TS: Sonar... sonar.language=ts ...
sonar-project.properties:
Laten we de scanner opnieuw starten en het resultaat bekijken:De dekking is helemaal verdwenen.
Als we in de scannerlog kijken, kunnen we de volgende regel zien:
Dat betekent dat de bestanden van ons project gewoon niet zijn geïndexeerd.
De situatie is als volgt: de officiële ondersteuning voor
VueJs is er in de plugin , die verantwoordelijk is voor , en voor TypescriptMaar deze ondersteuning ontbreekt in de plugin Javascript.
, waarvan een officieel ticket is aangemaakt in de bugtracker. Om informatie over de dekking te verzenden, gebruiken we de officiële client voor TSHier zijn enkele reacties van een van de vertegenwoordigers van de SonarQube-ontwikkelaars, die dit feit bevestigen. Sonar... sonar.language=ts ...
Maar het werkte allemaal, zult u tegenwerpen. Ja, dat klopt, laten we proberen om een beetje
“te hacken” Als er ondersteuning is voor.
.vue -bestanden.-bestanden SonarAls dat zo is, laten we dan proberen hem te zeggen dat hij ze als zodanig beschouwt Voor het opzetten van de server.
Laten we een parameter toevoegen:
sonar-project.properties:
...
sonar.typescript.file.suffixes=.ts,.tsx,.vue
...Laten we de scanner starten:
En, voilà, alles is terug zoals het was, met één profiel alleen voor Voor het opzetten van de server. Dat wil zeggen, het probleem met ondersteuning is opgelost VueJs+TS voor SonarQube.
Laten we een stap verder gaan en de informatie over de dekking iets verbeteren.
Wat hebben we tot nu toe gedaan:
- toegevoegd aan het project Sonar-scanner;
- geconfigureerd Jest voor het genereren van informatie over de dekking;
- geconfigureerd Sonar-scanner;
- een probleem met ondersteuning opgelost -bestanden.-bestanden + Voor het opzetten van de server.
Naast testdekking zijn er andere interessante nuttige kwaliteitscriteria van code, zoals code duplicatie en het aantal regels (helpt bij het berekenen van complexiteitscoëfficiënten) van het project.
In de huidige implementatie van de plugin voor het werken met TS (Om informatie over de dekking te verzenden, gebruiken we de officiële client) zal niet werken CPD (Copy Paste Detector) en het tellen van regels code -bestanden.-bestanden.
Om een synthetische situatie voor code duplicatie te creëren, dupliceren we gewoon het componentbestand met een andere naam, en voegen we ook een main.ts lege functie toe en dupliceren we deze met een andere naam. Om duplicatie te controleren zoals in -bestanden., alsook in .ts -bestanden.
main.ts:
...
funtie naam(params:string): void {
console.log(params);
}
...Hiervoor moeten we tijdelijk de regel in de configuratie uitcommentariëren:
sonar-project.properties:
...
sonar.exclusions=src/main.ts
...Laten we de scanner samen met de tests opnieuw opstarten:
yarn test && yarn run sonarOnze dekking zal uiteraard dalen, maar dat is nu niet interessant voor ons.
In het kader van code regel duplicatie zullen we zien:
Voor de controle gebruiken we CPD-tool – jscpd:
npx jscpd src
Voor de regels code:
Misschien wordt dit opgelost in toekomstige versies van de plugins SonarJS(TS). Ik wil opmerken dat ze deze twee plugins geleidelijk aan in één samenvoegen , en voor Typescript, wat ik denk dat juist is.
Nu willen we een manier overwegen om de informatie over de dekking te verbeteren.
Tot nu toe zien we de testdekking in procenten, voor het hele project, en per bestand. Maar er is een mogelijkheid om deze indicator uit te breiden met informatie over het aantal type-tests in het project, evenals per bestand.
Er is een bibliotheek die kan Jest-de rapporten omzetten naar indeling voor Sonar... sonar.language=ts ...
generic test data — .
Laten we deze bibliotheek aan ons project toevoegen:
yarn add jest-sonar-reporterEn laten we deze toevoegen aan de configuratie Jest:
package.json:
…
"testResultsProcessor": "jest-sonar-reporter"
…Laten we nu de test uitvoeren:
yarn testDaarna wordt er een bestand gemaakt in de hoofdmap van het project test-report.xml.
Laten we dit inschakelen in de configuratie Sonar... sonar.language=ts ...
sonar-project.properties:
…
sonar.testExecutionReportPaths=test-report.xml
…En laten we de scanner opnieuw starten:
yarn run sonarLaten we eens kijken wat er veranderd is in de interface Sonar... sonar.language=ts ...
En er is niets veranderd. Het punt is dat Sonar de bestanden die in het Jest-rapport zijn beschreven niet als type-tests beschouwt. Om deze situatie op te lossen, gebruiken we een configuratieparameter Sonar sonar.tests, waarin we expliciet de mappen met tests opgeven (we hebben er voorlopig maar één):
sonar-project.properties:
…
sonar.tests=src/components/__tests__
…Laten we de scanner opnieuw starten:
yarn run sonarLaten we eens kijken wat er veranderd is in de interface:
Nu hebben we het aantal van onze type-tests gezien en, door erop te klikken, kunnen we de verdeling van dit aantal over de projectbestanden bekijken:
Conclusie
Dus, we hebben het hulpmiddel voor continue analyse bekeken SonarQube. We hebben het succesvol geïntegreerd in een project geschreven in VueJs+TS. We hebben enkele compatibiliteitsproblemen opgelost. We hebben de informativiteit van de testdekking verhoogd. In dit artikel hebben we slechts één van de kwaliteitcriteria van de code behandeld (mogelijk een van de belangrijkste), maar SonarQube ondersteunt ook andere kwaliteitcriteria, waaronder beveiligingstests. Maar niet al deze mogelijkheden zijn volledig beschikbaar in de community-versie. Een van de interessante en nuttige mogelijkheden is de integratie SonarQube met verschillende systemen voor versiebeheer van code, zoals GitLab en BitBucket. Om te voorkomen dat merge pull (merge) requestin de hoofdbranch van de repository bij een degradatie van de dekking. Maar dat is een verhaal voor een heel ander artikel.
PS: Alles wat in het artikel als code is beschreven, is beschikbaar in .
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Maak je gebruik van het SonarQube-platform:
26,3%Ja5
15,8%Nee3
15,8%Ik heb gehoord van dit platform en wil het gebruiken3
10,5%Ik heb gehoord van dit platform en wil het niet gebruiken2
0,0%Ik gebruik een ander platform0
31,6%Ik hoor er voor het eerst over6
Er hebben 19 gebruikers gestemd. 3 gebruikers hebben zich onthouden.
Bron: habr.com
