Sonarqube Gurke Gherkin Analysator
Haftungsausschluss
Ich möchte dieses Plugin nicht weiterhin aufrechterhalten. Fühlen Sie sich frei, mich zu pingen, wenn Sie übernehmen möchten.
Beschreibung
Dieses Sonarqube -Plugin analysiert Gurken -Gherkin -Funktionsdateien und:
- Berechnet Metriken: Codezeilen, Anzahl der Szenarien usw.
- Überprüft verschiedene Richtlinien, um potenzielle Fehler und Codegerüche durch mehr als 40 Schecks herauszufinden
- Bietet die Möglichkeit, Ihre eigenen Schecks zu schreiben
Verwendung
- Laden Sie Sonarqube herunter und installieren Sie sie
- Installieren Sie das Gurken -Gherkin -Plugin durch einen direkten Download. Die neueste Version ist mit Sonarqube 6.7+ kompatibel.
- Installieren Sie Ihren bevorzugten Scanner (Sonarqube -Scanner, Maven, Ant usw.)
- Analysieren Sie Ihren Code
Maven
Es ist wahrscheinlich, dass sich Ihre Feature -Dateien nicht in Quellcodeverzeichnissen, sondern in Testverzeichnissen befinden. Standardmäßig analysiert Sonarqube diese Testverzeichnisse nicht. Daher müssen Sie Sonarqube explizit sagen, dass sie auch die Testverzeichnisse mit Ihren Feature -Dateien analysieren sollen.
Nehmen wir an, die Struktur Ihres Projekts lautet:
pom.xml
src
|-- main
|-- java
|-- resources
|-- test
|-- java
|-- resources
|-- features
|-- my-feature.feature
|-- my-other-feature.feature
In Ihrer POM -Datei müssen Sie hinzufügen:
<properties>
<sonar.sources>pom.xml,src/main/java,src/main/resources,src/test/resources/features</sonar.sources>
</properties>
Benutzerdefinierte Schecks
Sie denken an neue wertvolle Regeln? Version 1.0 oder mehr bietet eine API, um Ihre eigenen benutzerdefinierten Schecks zu schreiben. Ein Beispiel -Plugin mit detaillierten Erklärungen finden Sie hier. Wenn Ihre benutzerdefinierten Regeln der Community zugute kommen können, können Sie eine Pull -Anfrage erstellen, um die Regel im Gurken -Gherkin -Analysator verfügbar zu machen.
Sie denken an neue Regeln, die der Community zugute kommen können, aber nicht die Zeit oder die Fähigkeiten haben, sie zu schreiben? Fühlen Sie sich frei, ein Problem zu erstellen, damit Ihre Regeln berücksichtigt werden sollen.
Metriken
Aussagen
Anzahl der Schritte.
Funktionen
Anzahl der Szenarien und Szenario -Umrisse.
Klassen
Anzahl der Funktionen.
Verfügbare Regeln
- "Fixme" -Tags sollten behandelt werden
- "Todo" -Tags sollten gehandhabt werden
- Alle Kommentare sollten konsequent formatiert werden
- Und und aber es sollten Präfixe anstelle von redundant gegeben/wenn/dann Präfixe verwendet werden
- Byte Order Mark (BOM) sollte nicht für UTF-8-Dateien verwendet werden
- Häufige gegebene Schritte sollten zum Hintergrund hinzugefügt werden
- Duplizierte Schritte sollten entfernt werden
- Endlinienzeichen sollten konsistent sein
- Beispiele Datentabellen sollten Daten mindestens zwei Datenzeilen enthalten
- Funktionen sollten in derselben Sprache geschrieben werden
- Funktionen sollten eine Beschreibung haben
- Funktionen sollten einen Namen haben
- Funktionen sollten einen eindeutigen Namen haben
- Funktionen sollten nicht zu viele Szenarien enthalten
- Funktionen, die kein Szenario definieren, sollten entfernt werden
- Dateinamen sollten einer Namenskonvention entsprechen
- Dateien sollten am Ende eine leere neue Zeile enthalten
- Dateien, die keine Funktion definieren, sollten entfernt werden
- Die angegebenen Schritte sollten einem regulären Ausdruck folgen
- Gegeben/wenn/dann sollten Schritte in der richtigen Reihenfolge definiert werden
- Linien sollten nicht mit nachverfolgenden Weißespaces enden
- Spalten fehlende Datentabellen sollten hinzugefügt werden
- Nicht geeignete Schritte sollten aus dem Hintergrund herausgezogen werden
- Es sollten nur Tags des Whitelist verwendet werden
- Regelmäßiger Ausdruck zum Kommentar
- Szenarien sollten mindestens eines von jedem angegebenen/wenn/dann Schritttyp definieren
- Szenarien sollten einen Namen haben
- Szenarien sollten einen eindeutigen Namen haben
- Szenarien sollten nicht zu viele Schritte enthalten
- Szenarien, die keinen Schritt definieren, sollten entfernt werden
- Der Quellcode sollte ordnungsgemäß eingerückt sein
- Rechtschreibfehler sollten repariert werden
- Stern (*) Stufenpräfixe sollten nicht verwendet werden
- Stufensätze sollten nicht zu lang sein
- Schritte des unbekannten Typs sollten nicht verwendet werden
- Tabellierungszeichen sollten nicht verwendet werden
- Tags sollten auf der richtigen Ebene definiert werden
- Tags sollten einer Namenskonvention entsprechen
- Tags sollten nicht auf Beispielen festgelegt werden
- Dann sollten die Schritte einen regulären Ausdruck befolgen
- Es sollte eine einzelne wenn Schritt pro Szenario geben
- Unbenutzte Variablen sollten entfernt werden
- Nutzlose Tags sollten entfernt werden
- Wenn Schritte einen regulären Ausdruck folgen sollten
- Die Formulierung sollte auf Geschäftsebene bleiben
