私は最近、独自の注釈の作成を開始し、TDD/BDD をスポーツするために、注釈を単体テストして、それらの明確な仕様を作成したいと考えています。ただし、注釈は基本的には、私の知る限り、実際に直接インスタンス化できない単なる派手なインターフェイスであるため、注釈を単体テストするためのリフレクション以外の方法はありますか?
4 に答える
注釈にはある程度の影響があります (そうでなければ、注釈を使用しても意味がありません)。したがって、注釈の存在をテストするのではなく、それが持つべき効果をテストしてください。
通常はテストを作成するものではありませんが、アノテーションを使用および悪用する一連のテスト クラスを作成して、メンバー値が格納されていること、正しいデフォルトがあることなどをテストすることができます。
もちろん、これは正しいターゲットで指定されたランタイム注釈でのみ機能します。
私の経験では、アノテーション自体が単体テストを保証するほど興味深いものになることはめったにありません。通常、テストが必要なのはアノテーションを使用するコードです。しかし、私は 100% コード カバレッジの思想家ではありません :-)
アノテーションの定義が正しいかどうかを単体テストできます: 有効な要素セットに適用できますか? 必要に応じて実行時に利用できますか? デフォルト値は正しく初期化されていますか? その後、アノテーションを処理するクラスの単体テストを行います。
あなたが指摘したように、テストするものは何もないので、それらを直接テストすることはできません。ただし、いくつかのことを証明できます。
- コード内の注釈を持つオブジェクトには、実行時に予想される注釈があります
- デフォルト値が初期化されました
- 注釈は、期待するものにバインドされます
単体テストで証明できることの 1 つは、実装がインターフェイスに準拠していることです。したがって、注釈が特定の動作またはプロパティを暗示する場合 (たとえばSerializable
、物事は実際にシリアライズ可能である必要があります)、テストでもこれを表現する必要があります。