第39條:注解優先于命名模式

這部分內容利用JUNIT 中的測試方法來說明注解優于命名模式。命名模式是依賴于對于方法的命名在實現約定,如在JUNIT4之前對于測試方法的約定是以test 結尾的方法。
命名模式有以下缺點:

1: 非常依賴約定,萬一命名拼寫錯誤,就會導致失敗
2:無法確保只應用于相應的元素上。
3: 無法提供參數值與程序元素關聯的方法。

而使用注解就可以避免上述問題。
后續的內容,作者主要在介紹如何使用注解:
@Repeatable可以讓一個注解在同一個元素上多次使用,其輔佐用是當重復使用一個注解之后,就會變成@Repeatable注解里面配置的那個注解。
如:

public static void main(String[] args) {
  Class<Text> clazz = Text.class;
  Method[] methods = clazz.getMethods();
  for (Method method : methods) {
    if (!method.getName().startsWith("test")) {
      continue;
    }
    System.out.println(method.getName()); //false
    System.out.println(method.isAnnotationPresent(AnnotationOne.class)); //true
  }
}

第一個輸出會是false 是因為:@AnnotationOne在一個方法上重復使用之后變成了:@AnnotationTwo。
第二個為true 則是因為.getAnnotationsByType(AnnotationOne.class)還是會返回兩個結果。


我在接觸到UnitTest 時就是直接接觸的JUNIT4, 之前沒有注意到還有那么多的限制。一般在系統中也是使用注解較多。讀這部分內容讓我聯想起了系統中之前大師和K同學做的autoTest 框架。其實就是混用了注解和命名模式。
@OwnerEmail 是使用了注解。而對于所有以autoTest 結尾的類才會自動運行則是命名模式。按書中的思想,其實改成@AutoTest 注解會更好一些。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容