単体テストで注釈の存在を確認できますか？
私はJava抽象クラスとそのN個の拡張によって形成されるクラス階層を持っています。抽象クラスには、@ Removeアノテーションが付けられたメソッドがあります。このアノテーションが削除された場合、すぐに失敗しないという例外を取得すると、メモリ不足の例外が発生する可能性があるため、リファクタリングでこのアノテーションが消えた場合は、できるだけ早く通知するようにしたいと思います。
私はGUTS（優れた単体テスト）を作成しようとしているので、テストでこの「技術要件」を文書化し、それを明記するテストケースを作成できると考えました。
しかし、これは機能ではなく、実装の詳細であり、メソッドの動作にはリンクされていません（メソッドは空である可能性がありますが、存在する必要があり、注釈を付ける必要があります）。
そのためのテストを作成しても大丈夫ですか、この注釈の存在を確認する他の方法はありますか？
はい、単体テストを作成します。アノテーションを削除すると、本番環境でメモリ不足のバグが発生する可能性があると言っています。それはキラーバグでしょう。テストがどういうわけか制限されるべきであるといういくつかの考えのためにそれを起こさせることは逆効果です。テストはあらゆる意味で正しさをチェックする必要があります。可能性のある問題を検出するのが早ければ早いほど、ユニットテストを実施してCIビルドに失敗することが、バグを防ぐ確実な方法です。そのようなバグの導入を防ぐために別のメカニズムを発明しようとすることは、価値があるように思えません。すべての新しい開発者には、機能的正当性テストがない「特殊なケース」を処理する方法の説明を与える必要があります。これは、開発者の時間を有効に活用していない可能性が高いです。
編集 BDDを行うチームは、ビジネス機能テストをパフォーマンステストなどの技術テストから分離する可能性があります。通常、チームには、コアビジネスロジックテストよりも実行頻度が低い統合テストなど、さまざまな種類のテストがあります。これは通常、ビルドプロファイルを使用して行われるため、フロー内の開発者は、高速のビジネスロジックテストを頻繁に実行し、コードをコミットする前に低速の統合テストを実行できます。 CIビルドはすべてのテストを実行します。
このような宣言的手法を使用して重要な関数を実装する場合、宣言を認識するフレームワークの部分を含む統合テストを使用する傾向があります。これにより、フレームワークの動作の変更、宣言の影響の誤解などから保護されます。アノテーションの存在をテストするだけでは、特定の動作が保証されるわけではありません。