4

注釈が getter メソッドから削除されたときにテストが失敗し、クラスの仕様が変更されたことを警告するように、クラスの仕様をテストしたかったのです。

class SomeBean{

   @XMLElement(name = "name")
   public String getName(){
     return name;
   }
}

class SomeBeanUnitTest{
   @Test
   public void test_getNameMustHaveAnnotation(){
      Method getNameMethod = SomeBean.class.getDeclaredMethod("getName", new Class<?>[]{});
      assertNotNull(getNameMethod.getAnnotation(XmlElement.class));
   }
}

宣言されたアノテーションのメソッドをテストすることは、クラスの仕様をチェックする適切な方法ですか? これにより、テストがより脆弱になりますが、注釈が getter メソッドから削除されたという適切なフィードバックが提供されます。そのようなテストを書くことは賢明ですか？

この状態は統合テストでもカバーされていますが、統合によって提供されるフィードバックは問題を指摘しません。

4

1 に答える 1

3

場合によります。

それは、その注釈がアプリケーションの動作にとってどれほど重要/重要であるかによって異なります。もちろん、これは非常に一般的に聞こえるかもしれません。アプリケーションが正しく機能するためには、すべてのコードが重要であると考える人がいるからです。

私自身の裏庭から例を挙げましょう。注釈テストを使用して、特定のインターフェイスを実装するクラスのメソッド[Transaction]が属性でマークされているかどうかを確認します。何でこれが大切ですか？次のことは非常に簡単です。

  • メソッドをマークするのを忘れる
  • 誤って属性を削除
  • 不幸な合流事故の犠牲者になる

さらに悪いことに、メソッドが でマークされていない[Transaction]場合、一見何も悪いことは起こりません。アプリケーションは正常に動作し、機能します。しかし、おそらくご想像のとおり、そのようなメソッドはトランザクションで実行されません。これにより、追跡が非常に困難な重大なエラーが発生することがあります。そのようなテスト/利益を書くコストは非常に低いです。

さて、@XMLElementアプリケーションが適切に動作するためにどれだけ重要であり、それが欠けていた場合にどれだけ重大なエラーが発生するかは、あなたが判断することです. 疑問がある場合は、コストと利益を比較検討してください。私としては、非決定論的で追跡/デバッグが困難なエラーを自動テスト (コストがかかり脆弱なものであっても) に置き換えることができれば、いつでもそうします。

于 2013-10-22T08:50:09.913 に答える