一般命名模式表明有些程序元素须要通过某种工具进行特殊处理。
比如:JUnit測试框架要求用户一定要用test作为測试方法名称的开头。这样的方法有几个严重的缺陷
首先。文字拼写错误会导致失败。可是没有不论什么提示。比方,把方法名称命名写成tsetSafety而
不是testSafety时。JUnit不错报错,可是也不会运行測试。
其次。无法确保它们仅仅用于对应的程序元素上。
比方。将每一个类命名为testSafety。是希望JUnit会
自己主动的測试这个类的全部方法。而无论什么方法名称, JUnit不会报错,也不会运行測试,由于它针对的
是方法名,不是类名。
再次,它们没有提供将參数值与程序元素关联的好方法。
比方。想要支持一种測试类别,它仅仅在抛出特
殊异常时才会成功。
异常类型本质是測试的一个參数,假设命名类不存在。或者不是一个异常,你仅仅有通过
执行后才干发现。
对于注解类型能够非常好的解决命名模式的缺点。只是仅仅能应用于无參static方法中。
public class Sample{
@Test public static void m1(){}
public static void m2(){}
@Test public static void m3(){ throw new RuntimeException("boom")}
public static void m4(){}
@Test public void m5(){}
public static void m6(){}
@Test public static void m7(){ throw new RuntimeException("carsh")}
public static void m8(){}
}
Sample类有8个静态方法,当中是个是被注解为測试,这4个中有2个抛出异常,m3和m7
另一个是实例方法m5,不属于有效注解。总之,4个測试方法一项通过,两项失败。另外
一项无效。