Kann ich das Vorhandensein einer Anmerkung in einem Komponententest überprüfen?

Ich habe eine Java-Klassenhierarchie, die aus einer abstrakten Klasse und N Erweiterungen davon besteht. In der abstrakten Klasse habe ich eine Methode, die mit einer @ Remove-Annotation versehen ist. Obwohl wir keine Ausnahmen von erhalten, die nicht schnell fehlschlagen, wenn diese Annotation entfernt wird, können Ausnahmen vom Speicher ausgehen. Daher möchte ich sichergehen, dass wir dies so schnell wie möglich bemerken, wenn diese Annotation bei einem Refactoring verschwindet.

Ich versuche, GUTS (gute Komponententests) zu erstellen, daher dachte ich, ich könnte diese "technische Anforderung" in meinen Tests mit einem Testfall dokumentieren, in dem dies angegeben ist.

Dies ist jedoch keine Funktion, sondern ein Implementierungsdetail und nicht mit dem Verhalten der Methode verknüpft (die Methode kann leer sein, muss jedoch vorhanden sein und mit Anmerkungen versehen werden).

Ist es in Ordnung, einen Test dafür zu erstellen, oder gibt es eine andere Möglichkeit, das Vorhandensein dieser Anmerkung zu überprüfen?

Ja, erstellen Sie einen Komponententest. Sie sagen, wenn die Anmerkung entfernt wird, können Speicherfehler in der Produktion auftreten. Das wäre ein Killer-Bug. Dies zuzulassen, weil die Idee besteht, dass Tests irgendwie eingeschränkt werden sollten, ist kontraproduktiv. Tests sollten die Richtigkeit in jeder Hinsicht überprüfen. Je früher Sie das mögliche Problem erkennen, desto besser ist es, einen Unit-Test durchzuführen und den CI-Build nicht zu bestehen, um den Fehler zu vermeiden. Der Versuch, einen anderen Mechanismus zu erfinden, um die Einführung eines solchen Fehlers zu verhindern, scheint sich nicht zu lohnen. Jeder neue Entwickler muss eine Erklärung erhalten, wie er mit dem "Sonderfall" ohne funktionale Korrektheitstests umgehen soll. Das ist höchstwahrscheinlich keine gute Nutzung der Entwicklerzeit.

Bearbeiten Teams, die BDD durchführen, trennen Geschäftsfunktionstests wahrscheinlich von technischen Tests wie Leistungstests. In der Regel haben Teams verschiedene Arten von Tests, einschließlich Integrationstests, die weniger häufig ausgeführt werden als ihre Kerngeschäftslogiktests. Dies erfolgt normalerweise mit Build-Profilen, damit Entwickler in ihrem Ablauf häufig schnelle Geschäftslogiktests und langsamere Integrationstests ausführen können, bevor sie Code festschreiben. Der CI-Build führt alle Tests aus.

Wenn eine kritische Funktion mit einer solchen deklarativen Technik implementiert wird, bevorzuge ich die Verwendung eines Integrationstests, der den Teil des Frameworks enthält, der die Deklaration erkennt. Dies schützt Sie vor Änderungen im Framework-Verhalten, Missverständnissen hinsichtlich der Auswirkung der Deklaration usw. Das einfache Testen des Vorhandenseins der Anmerkung garantiert kein bestimmtes Verhalten.