In diesem Blogbeitrag werden wir:

• Suchen und Abgleichen von Anmerkungen demonstrieren
• Amen-Bemerkungen mit Schnurrbartvorlagen

Sensei bietet die Möglichkeit, problematische Codemuster abzugleichen und sie dann an vereinbarte Implementierungen anzupassen. In diesem Beispiel verwende ich @Disabled ohne einen Parameter als problematisches Codemuster.

Deaktivierte Testanmerkung

Deaktivierte Tests ohne angegebenen Grund können sich langfristig als problematisch erweisen, weil wir vergessen, warum wir sie deaktiviert haben.

@Disabled
   void thisTestMethodHasNoDisabledReason(){
    Assertions.fail("This test is disabled and should not run");
    }

Das Risiko besteht darin, dass sich die Codebasis im Laufe der Zeit weiterentwickelt, der deaktivierte Test nicht im Gleichschritt mit dem Zweck des Codes aktualisiert wird und schließlich redundant und irrelevant wird und möglicherweise nie wieder aktiviert wird.

Bei Code-Reviews werden wir oft darauf hinweisen, dass es sinnvoll ist, eine erklärende Beschreibung als Annotationsparameter hinzuzufügen.

@Disabled ("Disabled to demonstrate adding a reason")
    void thisTestMethodHasDisabledReason(){
   Assertions.fail("This test is disabled and should not run");
   }

Ein Sensei Rezept

Wir können ein Rezept schreiben, das erkennt, wenn @Disabled ohne Erklärung hinzugefügt wird, und einen Quick Fix, der uns daran erinnert, den tatsächlichen Grund für die Deaktivierung hinzuzufügen.

Wenn ich darüber nachdenke, was ich tun werde, muss ich es tun:

• entspricht der Disabled-Anmerkung ohne Parameter
• die Anmerkung "Disabled" so ändern, dass sie einen Parameter mit dem Markierungstext "TODO: fügen Sie hier eine Beschreibung ein" hat

Ein Warnrezept erstellen

Ich verwende Alt+Eingabe, um ein neues Rezept zu erstellen.

Fügen Sie dann den grundlegenden beschreibenden Text in den allgemeinen Informationen hinzu.

Wenn Sie die Regel zu einer Warnung machen, wird jeder übereinstimmende Code hervorgehoben, aber nicht als eklatanter Fehler angezeigt.

Finden Sie die Bemerkung

Im Rezepteditor ändere ich die Suche so, dass sie mit einer Bemerkung übereinstimmt.

Dadurch werden alle Anmerkungen in der Vorschau hervorgehoben.

Danach möchte ich nach dem Typ der Anmerkung filtern.

Ich könnte einfach Disabled verwenden, aber ich qualifiziere die Klasse vollständig mit dem Paket, sodass sie nur mit der Annotation von JUnit 5 übereinstimmt. Da der Quellcode in der Vorschau angezeigt wird, kann ich diesen einfach kopieren und aus dem eigentlichen Code einfügen, um Tippfehler zu vermeiden.

Ich möchte dann nur Annotationen ohne Parameter abgleichen, und das kann ich mit der GUI machen.

d.h. Suche:

search:
  annotation:
    type: "org.junit.jupiter.api.Disabled"
    without:
       parameters:
          - {}

Erstellen einer Aktion "Schnellreparatur neu schreiben

Für meinen QuickFix werde ich eine Rewrite-Aktion verwenden.

Ich verwende die Funktion " Variablen anzeigen", um mir die Mustache-Variablen anzeigen zu lassen und eine Vorschau des Inhalts zu erhalten.

Und dann füge ich den zusätzlichen Code hinzu, der benötigt wird, um den Platzmarkenkommentar zu erstellen.

d.h. QuickFix:

availableFixes:
 - name: "Add a todo comment parameter"
   actions:
   - rewrite:
      to: "{{{ . }}}(\"TODO: add a description here\")"
      target: "self"

Sensei in Aktion

Wir haben ein kurzes Video erstellt, das den Prozess der Rezepterstellung in Aktion zeigt.

Zusammenfassung

Beim Erstellen eines Rewrite-Quick-Fix ist es einfacher, wenn wir nach dem Code-Element suchen können, das wir umschreiben wollen, weil es dann die eigene Entität ist, auf die wir einwirken können.

In diesem Beispiel habe ich eine Rewrite-Aktion verwendet, um die Annotation zu ändern. Rewrite ist eine universelle Aktion, die auf jedes Code-Element angewendet werden kann und eine gute Voreinstellung ist, um sie zu erkunden.