単体テストで注釈の存在を確認できますか？

抽象クラスとそのN個の拡張によって形成されるJavaクラス階層があります。抽象クラスには、@ Removeアノテーションが付けられたメソッドがあります。このアノテーションが削除されても例外がすぐに失敗することはありませんが、メモリ不足の例外が発生する可能性があるため、このアノテーションがリファクタリングで消えた場合は、できるだけ早く通知するようにしたいと思います。

私はGUTS（優れた単体テスト）を作成しようとしているので、テストでこの「技術要件」を文書化し、それを明記するテストケースを作成できると考えました。

しかし、これは機能ではなく、実装の詳細であり、メソッドの動作にはリンクされていません（メソッドは空である可能性がありますが、存在し、注釈が必要です）。

そのためのテストを作成しても大丈夫ですか、またはこの注釈の存在を確認する他の方法はありますか？

はい、単体テストを作成します。アノテーションを削除すると、本番環境でメモリ不足のバグが発生する可能性があると言っています。それはキラーバグでしょう。テストが何らかの形で制限されるべきであるという考えのためにそれを起こさせることは逆効果です。テストはあらゆる意味で正しさをチェックする必要があります。可能性のある問題をより早く検出するほど、ユニットテストを実施し、CIビルドに失敗することが、バグを防ぐ確実な方法です。そのようなバグの導入を防ぐために別のメカニズムを発明しようとすることは、価値があるように思えません。すべての新しい開発者には、機能的正当性テストがない「特殊なケース」を処理する方法の説明を与える必要があります。これは、開発者の時間を有効に活用していない可能性があります。

BDDを行う編集チームは、ビジネス機能テストをパフォーマンステストなどの技術テストから分離する可能性があります。通常、チームには、コアビジネスロジックテストよりも実行頻度が低い統合テストなど、さまざまな種類のテストがあります。これは通常、ビルドプロファイルを使用して行われるため、フロー内の開発者は、高速のビジネスロジックテストを頻繁に実行し、コードをコミットする前に低速の統合テストを実行できます。CIビルドはすべてのテストを実行します。

このような宣言的手法を使用して重要な機能を実装する場合、宣言を認識するフレームワークの部分を含む統合テストを使用する傾向があります。これにより、フレームワークの動作の変更、宣言の影響の誤解などから保護されます。アノテーションの存在をテストするだけでは、特定の動作が保証されるわけではありません。