In unserer Arbeit nutzen wir aktiv die Plattform SonarQube zur Aufrechterhaltung der Codequalität auf hohem Niveau. Bei der Integration eines Projekts, das in VueJs+Typescript, gab es Probleme. Deshalb möchte ich ausführlicher darüber berichten, wie wir sie gelöst haben.

In diesem Artikel geht es, wie ich bereits erwähnt habe, um die Plattform SonarQube. Ein bisschen Theorie — was ist das überhaupt, für diejenigen, die zum ersten Mal davon hören:

SonarQube (ehemals Sonar) — eine Open-Source-Plattform für kontinuierliche Analyse (engl. continuous inspection) und Messung der Codequalität.
Sie unterstützt die Codeanalyse und die Fehlersuche gemäß den Regeln der Programmierstandards MISRA C, MISRA C++, MITRE/CWE und CERT Secure Coding Standards. Zudem kann sie Fehlertypen aus den OWASP Top-10 und CWE/SANS Top-25 Programmierfehlern erkennen.
Obwohl die Plattform verschiedene fertige Tools verwendet, fasst SonarQube die Ergebnisse in einem einheitlichen Dashboard zusammen, führt die Historie der Durchläufe und ermöglicht es damit, die allgemeine Tendenz in der Veränderung der Softwarequalität während der Entwicklung zu erkennen.

Detailliertere Informationen gibt es auf der offiziellen Website

Es werden eine Vielzahl von Programmiersprachen unterstützt. Laut den Informationen im obigen Link sind es über 25 Sprachen. Um eine bestimmte Sprache zu unterstützen, muss das entsprechende Plugin installiert werden. In der Community-Version ist ein Plugin für die Arbeit mit Javascript (einschließlich Typescript) enthalten, obwohl in der Wiki etwas anderes steht. Für Javascript verantwortet das Plugin SonarJS, für Typescript SonarTS entsprechend.

Um Informationen über die Abdeckung zu übermitteln, wird der offizielle Client sonarqube-scanner, der die Einstellungen aus config-Datei verwendet, auf den Server SonarQube diese Daten zur weiteren Konsolidierung und Aggregation sendet.

Für Javascript einen npm-Wrapper. Und so beginnen wir die schrittweise Implementierung SonarQube in Vue-Projekt, das Typescript.

verwendet. SonarQube Für die Bereitstellung des Servers nutzen wir docker-compose.

sonar.yaml:

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

Start:

docker-compose -f sonar.yml up

Nach diesem Schritt SonarQube ist es unter der Adresse verfügbar – http://localhost:9001 .

Aktuell sind keine Projekte vorhanden, und das ist gerechtfertigt. Wir werden diese Situation verbessern. Ich habe das offizielle Beispielprojekt für VueJS+TS+Jestals Grundlage genommen. Wir klonen es lokal:

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

Zuerst müssen wir den Client installieren, SonarQube, der den Namen sonar-scanner, für npm gibt es eine Wrapper:

yarn add sonarqube-scanner

Und sofort fügen wir den Befehl in scripts für die Nutzung hinzu.

package.json:

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

Um den Scanner zu betreiben, müssen die Projekteinstellungen in einer speziellen Datei festgelegt werden. Beginnen wir mit den Grundlagen.

sonar-project.properties:

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

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

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

sonar.host.url – Adresse Sonar’a;
sonar.projectKey – eindeutige Kennung des Projekts auf dem Server Sonar’a;
sonar.projectName – dessen Bezeichnung, die jederzeit geändert werden kann, da die Identifizierung des Projekts anhand des projectKey erfolgt;
sonar.sources – Ordner mit den Quelldateien, normalerweise ist das src, kann jedoch beliebig sein. Dieser Ordner wird relativ zum Wurzelverzeichnis festgelegt, von dem der Scanner gestartet wurde;
sonar.tests – Parameter, der mit dem vorherigen verbunden ist. Dies ist der Ordner, in dem sich die Tests befinden. In diesem Projekt gibt es keinen solchen Ordner, und der Test befindet sich neben der zu testenden Komponente im Ordner 'test‘, daher ignorieren wir ihn vorerst und verwenden den folgenden Parameter;
sonar.test.inclusions – Pfad für die Tests unter Verwendung von Mustern, es können mehrere Elemente durch Kommas getrennt aufgeführt werden;
sonar.sourceEncoding – Kodierung für die Quelldateien.

Für den ersten Start des Scanners ist alles bereit, außer der wichtigsten vorhergehenden Aktion: dem Start der Test-Engine, um Informationen über die Abdeckung zu generieren, die der Scanner später verwenden wird.

Aber dafür muss die Test-Engine so konfiguriert werden, dass diese Informationen generiert werden. In diesem Projekt ist die Test-Engine – das ist Jest. Und seine Einstellungen befinden sich im entsprechenden Abschnitt der Datei package.json.

Fügen wir diese Einstellungen hinzu:

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

Das heißt, wir setzen das Flag für die Notwendigkeit der Abdeckungsberechnung und die Quelle (einschließlich der Ausnahmen), auf deren Grundlage sie generiert wird.

Jetzt starten wir den Test:

yarn test

Wir werden Folgendes sehen:

Der Grund ist, dass im eigentlichen Komponentene keinen Code gibt. Lassen Sie uns das beheben.

HelloWorld.vue:

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

Das wird ausreichend sein, um die Abdeckung zu berechnen.

Nach dem Neustart des Tests werden wir uns davon überzeugen:

Auf dem Bildschirm sollten wir Informationen zur Abdeckung sehen, und im Projektverzeichnis wird ein Ordner erstellt coverage mit Informationen zur Testabdeckung im universellen Format LCOV (LTP GCOV-Erweiterung).

Gcov — eine frei verbreitete Dienstprogramm zur Analyse der Codeabdeckung. Gcov erzeugt die genaue Anzahl der Ausführungen für jeden Operator im Programm und erlaubt es, Anmerkungen zum Quellcode hinzuzufügen. Gcov wird als Standard-Dienstprogramm im GCC-Paket geliefert.
Lcov — eine grafische Benutzeroberfläche für gcov. Es sammelt gcov-Dateien für mehrere Quellcode-Dateien und erstellt ein Set von HTML-Seiten mit Code und Abdeckungsinformationen. Außerdem werden Seiten zur vereinfachten Navigation generiert. Lcov unterstützt die Abdeckung von Zeilen, Funktionen und Verzweigungen.

Nach der Ausführung der Tests wird die Abdeckungsinformation in coverage/lcov.info.
Wir müssen sagen Sonarwoher sie kommt. Daher fügen wir folgende Zeilen in die Konfigurationsdatei ein. Es gibt allerdings einen Punkt zu beachten: Projekte können mehrsprachig sein, das heißt, im Ordner src befinden sich Quellcodes für mehrere Programmiersprachen, und die Zuordnung zu einer bestimmten Sprache sowie die Verwendung eines bestimmten Plugins wird durch die Dateierweiterung bestimmt. Zudem kann die Abdeckungsinformation an verschiedenen Orten für verschiedene Programmiersprachen gespeichert werden, weshalb jeder Programmiersprache ein eigener Abschnitt zur Konfiguration bereitsteht. Unser Projekt verwendet Typescript, daher benötigen wir einen speziellen Einstellungsabschnitt für ihn:

sonar-project.properties:

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

Alles ist bereit für den ersten Start des Scanners. Ich möchte darauf hinweisen, dass das Projekt in Sonarautomatisch beim ersten Start des Scanners für dieses Projekt erstellt wird. Bei den folgenden Ausführungen wird die Information bereits akkumuliert, um die Dynamik der Veränderungen der Projektparameter über die Zeit sichtbar zu machen.

Lassen Sie uns also den Befehl verwenden, der zuvor in package.json:

yarn run sonar

Hinweis: auch mit dem Parameter -X für detailliertere Protokollierung genutzt werden kann.

Wenn der Scanner zum ersten Mal gestartet wurde, wird zunächst das Binärprogramm des Scanners heruntergeladen. Danach wird er gestartet und beginnt, den Server Sonarauf installierte Plugins zu prüfen, wodurch die unterstützten Programmiersprachen berechnet werden. Auch verschiedene andere Parameter für seinen Betrieb werden heruntergeladen: Qualitätsprofile, aktive Regeln, Metriken-Repository, Serverregeln.

Hinweis: im Rahmen dieses Artikels werden wir nicht näher darauf eingehen, aber es kann jederzeit auf offizielle Quellen verwiesen werden.

Anschließend beginnt die Analyse des Ordners src zum Vorhandensein von Quelldateien für alle (es sei denn, es wurde ausdrücklich ein bestimmter angegeben) unterstützten Programmiersprachen mit anschließender Indizierung.

Hier folgen verschiedene andere Analysen, auf die wir in diesem Artikel nicht näher eingehen (zum Beispiel: Linting, Erkennung von Code-Duplikaten usw.).

Am Ende der Scannerarbeit erfolgt die Aggregation aller gesammelten Informationen, die Archivierung und der Versand an den Server.

Nach dem können wir sehen, was im Web-Interface herausgekommen ist:

Wie zu sehen ist, ist etwas herausgekommen, und es zeigt sogar eine gewisse Abdeckung, aber sie entspricht nicht unserem Jest- Bericht.

Lass uns das klären. Schauen wir uns das Projekt im Detail an, klicken wir auf den Abdeckungswert und "tauchen wir" in den detaillierten Bericht der Dateien ein:

Hier sehen wir neben der Haupt-, untersuchten Datei HelloWorld.vue, auch die Datei main.ts, die das gesamte Bild der Abdeckung stört. Aber wie kann das sein, wir haben sie aus der Abdeckung ausgeschlossen. Ja, das stimmt, aber das war auf der Ebene Jest, aber der Scanner hat sie indiziert, deshalb ist sie in seine Berechnungen eingeflossen.

Lass es uns beheben:

sonar-project.properties:

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

Ich möchte klarstellen: Neben den in diesem Parameter angegebenen Ordnern werden auch alle Ordner hinzugefügt, die im Parameter sonar.test.inclusions.

aufgeführt sind. Nach dem Start des Scanners sehen wir bereits korrekte Informationen:

Betrachten wir den nächsten Punkt – Qualitätsprofile. Ich habe oben erwähnt, dass mehrere Programmiersprachen gleichzeitig unterstützt werden. Genau das sehen wir hier. Aber wir wissen, dass unser Projekt in SonarTS TS, geschrieben wurde, warum also den Scanner mit unnötigen Manipulationen und Überprüfungen belasten? Die Sprache zur Analyse legen wir durch das Hinzufügen eines weiteren Parameters in die Konfigurationsdatei fest Sonar:

sonar-project.properties:

...
sonar.language=ts
...

Lass uns den Scanner erneut starten und das Ergebnis ansehen:

Die Abdeckung ist ganz verschwunden.

Wenn wir im Protokoll des Scanners nachsehen, können wir die folgende Zeile sehen:

Das bedeutet, dass die Dateien unseres Projekts einfach nicht indiziert wurden.

Die Situation ist folgende: Die offizielle Unterstützung für VueJs besteht im Plugin SonarJS, das für Javascript.

verantwortlich ist. SonarTS für TSAber diese Unterstützung gibt es nicht im Plugin, was in einem offiziellen Ticket im Bug-Tracker vermerkt ist. Sonar:

Hier sind einige Antworten eines der Vertreter seitens der Entwickler von SonarQube, die diesen Fakt bestätigen.

Aber es hat doch alles bei uns funktioniert, werden Sie einwenden. Ja, das stimmt, lass uns versuchen, ein wenig zu "hacken"..
Wenn es Unterstützung für .vue-Dateien gibt. Sonardann lassen Sie uns versuchen, ihm zu sagen, dass er diese als Typescript.

Fügen wir einen Parameter hinzu:

sonar-project.properties:

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

Lassen Sie uns den Scanner starten:

Und voila, alles ist wieder beim alten, und mit einem Profil nur für Typescript. Das heißt, wir haben das Problem mit der Unterstützung VueJs+TS für SonarQube.

Lassen Sie uns weitergehen und die Abdeckungsinformationen ein wenig verbessern.

Was haben wir bis jetzt getan:

wir haben im Projekt hinzugefügt Sonar-Scanner;
haben wir konfiguriert Jest um Abdeckungsinformationen zu erstellen;
haben wir konfiguriert Sonar-Scanner;
haben das Problem mit der Unterstützung gelöst .vue-Dateien + Typescript.

Neben der Testabdeckung gibt es noch andere interessante Qualitätskriterien für den Code, wie z.B. Code-Duplikation und die Anzahl der Zeilen (die bei der Berechnung von Faktoren, die mit der Code-Komplexität zusammenhängen, berücksichtigt werden).

In der aktuellen Implementierung des Plugins funktioniert TS (SonarTS) nicht CPD (Copy Paste Detector) und die Zählung der Codezeilen .vue-Dateien.

Um eine synthetische Situation zur Code-Duplikation zu schaffen, duplizieren wir einfach die Komponentendatei mit einem anderen Namen und fügen auch im Code main.ts eine Platzhalterfunktion hinzu und duplizieren sie mit einem anderen Namen. Um die Duplikation sowohl in .vue, als auch in .ts -Dateien.

main.ts:

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

Dazu müssen wir vorübergehend die Zeile mit der Konfiguration auskommentieren:

sonar-project.properties:

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

Lassen Sie uns den Scanner zusammen mit den Tests neu starten:

yarn test && yarn run sonar

Natürlich wird unsere Abdeckung sinken, aber das interessiert uns jetzt nicht.

Im Hinblick auf die Duplikation der Codezeilen sehen wir:

Für die Prüfung verwenden wir CPD-Utility – jscpd:

npx jscpd src

Für Codezeilen:

Vielleicht wird das in zukünftigen Versionen der Plugins SonarJS(TS)gelöst. Ich möchte anmerken, dass sie allmählich beginnen, diese beiden Plugins zu einem zu verschmelzen SonarJS, was ich denke, ist richtig.

Jetzt möchten wir die Möglichkeit zur Verbesserung der Abdeckungsinformationen betrachten.

Bis jetzt sehen wir die Testabdeckung in Prozent über das gesamte Projekt und spezifisch für die Dateien. Aber es gibt die Möglichkeit, diesen Wert mit Informationen über die Anzahl der Unit-Tests im Projekt zu erweitern, sowie im Hinblick auf die Dateien.

Es gibt eine Bibliothek, die in der Lage ist, Jest-Reporte in das Format für Sonar:
generic test data — https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Lassen Sie uns diese Bibliothek in unser Projekt integrieren:

yarn add jest-sonar-reporter

Und fügen wir es in die Konfiguration ein Jest:

package.json:

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

Führen wir jetzt den Test durch:

yarn test

Nach dem wird im Wurzelverzeichnis des Projekts eine Datei erstellt test-report.xml.

Nutzen Sie sie in der Konfiguration Sonar:

sonar-project.properties:

…
sonar.testExecutionReportPaths=test-report.xml
…

Und starten Sie den Scanner neu:

yarn run sonar

Lassen Sie uns sehen, was sich in der Oberfläche geändert hat. Sonar:

Und es hat sich nichts geändert. Das liegt daran, dass Sonar Dateien, die im Jest-Bericht beschrieben sind, nicht als Testdateien betrachtet. Unit-Tests. Um diese Situation zu beheben, verwenden wir den Konfigurationsparameter Sonar sonar.tests, in dem wir die Ordner mit den Tests ausdrücklich angeben (wir haben derzeit nur einen):

sonar-project.properties:

…
sonar.tests=src/components/__tests__
…

Starten wir den Scanner neu:

yarn run sonar

Lassen Sie uns sehen, was sich in der Oberfläche geändert hat:

Jetzt haben wir die Anzahl unserer Unit-Tests gesehen und können, indem wir darauf klicken, die Verteilung dieser Zahl auf die Projektdateien einsehen:

Fazit

Also haben wir ein Tool für die kontinuierliche Analyse betrachtet. SonarQubeWir haben es erfolgreich mit einem Projekt integriert, das in VueJs+TSgeschrieben wurde. Einige Kompatibilitätsprobleme wurden gelöst. Wir haben die Aussagekraft der Testabdeckungskennzahl erhöht. In diesem Artikel haben wir nur eines der Qualitätskriterien für Code betrachtet (möglicherweise eines der wichtigsten), aber SonarQube unterstützt auch andere Qualitätskriterien, einschließlich Sicherheitstests. Doch nicht alle diese Funktionen sind in vollem Umfang in der Community-Version verfügbar. Eine der interessanten und nützlichen Funktionen sind die Integrationen SonarQube mit verschiedenen Code-Repository-Management-Systemen, wie zum Beispiel GitLab und BitBucket. Um zu verhindern, dass Merge Pull-Requestin den Hauptzweig des Repositories bei einer Abnahme der Abdeckung integriert wird. Aber das ist eine ganz andere Geschichte.

PS: Alles, was in diesem Artikel in Form von Code beschrieben wird, ist in meinem Fork verfügbar..

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.