BlogJava-Jiangshachina-随笔分类-UnitTest

探索JUnit4扩展：深入Rule(原)

Sha Jiang — Tue, 03 Jan 2012 16:13:00 GMT

探索JUnit4扩展：深入Rule

本文是"探索JUnit4扩展"系列中的第三篇，将进一步探究Rule的应用，展示如何使用Rule来替代@BeforeClass，@AfterClass，@Before和@After的功能。(2012.01.04最后更新)

在本系列的第二篇《探索JUnit4扩展：应用Rule》中提到，可以使用Rule替代现有的大部分Runner扩展，而且也不提倡对Runner中的withBefores()，withAfters()等方法进行扩展。本文将介绍如何使用Rule去实现@Before，@After和@BeforeClass的相同功能。

1. BaseRule
首先要创建一个较通用的TestRule实现BaseRule，它会释放出两个扩展点，一个在执行测试方法之前，before()；另一个在执行测试方法之后after()。下面是该类的代码，

public abstract class BaseRule implements TestRule {

    @Override
    public Statement apply(Statement base, Description description) {
        return new RuleStatement(base, description);
    }

    private class RuleStatement extends Statement {

        private Statement base = null;

        private Description description = null;

        private RuleStatement(Statement base, Description description) {
            this.base = base;
            this.description = description;
        }

        @Override
        public void evaluate() throws Throwable {
            before(base, description);
            try {
                base.evaluate();
            } finally {
                after(base, description);
            }
        }
    }

    protected void before(Statement base, Description description) throws Throwable {

    }

    protected void after(Statement base, Description description) {

    }
}

如果对JUnit4的源代码略有认知，可能会发现BaseRule与JUnit4提供的TestRule实现ExternalResource代码相似。关键的不同之处是，BaseRule中的before()与after()方法都提供了Statement与Description类型的参数，这使得它能够完成更复杂的工作。

2. CalculatorTest
本文使用的CalculatorTest将不使用@BeforeClass，@Before和@After，而会创建两个BaseRule的实例：一个用于替代@BeforeClass和@AfterClass(本系列目前还未使用过@AfterClass)，另一个则替代@Before和@After。

public class CalculatorTest {

    private static final DateFormat format = new SimpleDateFormat("yyyy-MM-dd_HH:mm:ss_SSS");

    private static Calculator calculator = null;

    @ClassRule
    public static BaseRule classRule = new BaseRule() {

        protected void before(Statement base, Description description) throws Throwable {
            calculator = new Calculator();
        };
    };

    @Rule
    public BaseRule rule = new BaseRule() {

        protected void before(Statement base, Description description) throws Throwable {
            printBeforeLog(description);
        };

        protected void after(Statement base, Description description) {
            printAfterLog(description);
        };

        private void printBeforeLog(Description description) {
            TestLogger testLogger = description.getAnnotation(TestLogger.class);
            if (testLogger != null) {
                StringBuilder log = new StringBuilder(format.format(new Date()));
                log.append(" ").append(description.getClassName()).append("#")
                        .append(description.getMethodName()).append(": ")
                        .append(testLogger.log());
                System.out.println(log.toString());
            }
        }

        private void printAfterLog(Description description) {
            StringBuilder log = new StringBuilder(format.format(new Date()));
            log.append(" ").append(description.getClassName()).append("#")
                    .append(description.getMethodName()).append(" end");
            System.out.println(log.toString());
        }
    };

    @Test
    @TestLogger(log = "a simple division")
    public void simpleDivide() {
        int value = calculator.divide(8, 2);
        Assert.assertTrue(value == 4);
    }

    @Test(expected = ArithmeticException.class)
    @TestLogger(log = "divided by zero, and an ArithmeticException thrown.")
    public void dividedByZero() {
        calculator.divide(8, 0);
    }
}

值得注意的是，classRule是静态变量，它使用@ClassRule Annotation，将替代@BeforeClass和@AfterClass；而rule是成员变量，它使用@Rule Annotation，将替代@Before和@After。与之前文章不同的是，此处不仅会在执行测试方法之前打印指定内容的日志(printBeforeLog())，还会在执行测试方法之后打印一条固定格式的日志(printAfterLog())，用于指示该测试方法已经执行完毕了。

3. 小结
使用Rule可以替代绝大部分的Runner扩展，而且特定的Rule实现可以被复用，也易于添加或移除Rule实例，这些都大大地提高了灵活性。值得注意地是，本文虽然使用Rule代替了@BeforeClass，@AfterClass，@Before和@After的功能，但并不意味着就应当这么做。就我个人所想，将传统的Fixture功能交由@BeforeClass，@AfterClass，@Before和@After实现，仍然是一种不错的选择。

Sha Jiang 2012-01-04 00:13 发表评论

探索JUnit4扩展：应用Rule(原)

Sha Jiang — Sat, 24 Dec 2011 15:26:00 GMT

探索JUnit4扩展：使用Rule

在上一篇文章《探索JUnit4扩展：扩展Runner》中，讨论了一种扩展JUnit4的方式，即，直接修改Test Runner的实现(BlockJUnit4ClassRunner)。但这种方法显然不便于灵活地添加或删除扩展功能。本文将使用JUnit4.7才开始引入的扩展方式--Rule来实现相同的扩展功能。(2010.12.25最后更新)

1. Rule
Rule是JUnit4.7才开始提供的一种扩展方式，它能够替代大部分已有的Runner扩展。JUnit包含两种Rule Annotation：@ClassRule与@Rule。@ClassRule应用于测试类中的静态变量，而@Rule应用于成员变量；相同地是，这些变量必须是TestRule接口的实例，且访问修饰符必须为public。
在上篇博文中，对BlockJUnit4ClassRunner进行了扩展，被扩展的方法是methodBlock，现在我们来看看该方法体中的代码，

protected Statement methodBlock(FrameworkMethod method) {
    Object test;
    try {
        test= new ReflectiveCallable() {
            @Override
            protected Object runReflectiveCall() throws Throwable {
                return createTest();
            }
        }.run();
    } catch (Throwable e) {
        return new Fail(e);
    }

    Statement statement= methodInvoker(method, test);
    statement= possiblyExpectingExceptions(method, test, statement);
    statement= withPotentialTimeout(method, test, statement);
    statement= withBefores(method, test, statement);
    statement= withAfters(method, test, statement);
    statement= withRules(method, test, statement);
    return statement;
}

但在BlockJUnit4ClassRunner中，possiblyExpectingExceptions()，withPotentialTimeout()，withBefores()和withAfters()都已经被标注为过时，JUnit建议使用Rule来替代这些方法的功能。

2. TestLogRule
如第1节所述，Rule Annotation要作用于TestRule接口的实例，那么就要先创建一个TestRule的实现类。

public class TestLogRule implements TestRule {

    private static final DateFormat format = new SimpleDateFormat("yyyy-MM-dd_HH:mm:ss_SSS");

    @Override
    public Statement apply(Statement base, Description description) {
        TestLogger testLogger = description.getAnnotation(TestLogger.class);
        if (testLogger != null) {
            StringBuilder log = new StringBuilder(format.format(new Date()));
            log.append(" ").append(description.getClassName()).append("#")
                    .append(description.getMethodName()).append(": ")
                    .append(testLogger.log());
        System.out.println(log.toString());
    }

        return base;
    }
}

如上所示，TestLogRule与上篇博文中的LoggedRunner的代码有许多相同之处，功能则都是打印出指定的日志，每行日志又以当时的执行时间与完整方法名作为前缀。

3. 使用Rule的CalculatorTest
下面是新的测试类CalculatorTest，它将不使用BlockJUnit4ClassRunner的扩展LoggedRunner作为测试执行器，所以该类没有使用@RunWith(LoggedRunner.class)，那么在执行该测试类时仍然会使用BlockJUnit4ClassRunner。

public class CalculatorTest {

    private static Calculator calculator = null;

    @Rule
    public TestLogRule testLogRule = new TestLogRule();

    @BeforeClass
    public static void createCalculator() {
        calculator = new Calculator();
    }

    @Test
    @TestLogger(log = "a simple division")
    public void simpleDivide() {
        int value = calculator.divide(8, 2);
        Assert.assertTrue(value == 4);
    }

    @Test(expected = ArithmeticException.class)
    @TestLogger(log = "divided by zero, and an ArithmeticException thrown.")
    public void dividedByZero() {
        calculator.divide(8, 0);
    }
}

与上篇博文中的CalculatorTest相比，本文中的CalculatorTest除了没有使用LoggedRunner之外，还多了两行代码

@Rule
public TestLogRule testLogRule = new TestLogRule();

在执行单元测试方法之前，BlockJUnit4ClassRunner会调用TestRule/TestLogRule中的apply()方法，即，会先打印出日志内容。

4. 小结
使用Rule对JUnit进行扩展，能够避免对默认Runner的扩展，为测试类添加或移除Rule十分方便，而且Rule实现类本身也能很方便地被复用。在下一篇博文中将进一步探索Rule的应用。

Sha Jiang 2011-12-24 23:26 发表评论

探索JUnit4扩展：扩展Runner(原)

Sha Jiang — Tue, 13 Dec 2011 16:01:00 GMT

探索JUnit4扩展：扩展Runner

在使用JUnit的过程中，大家可能会对JUnit进行一些扩展。本文中的示例为JUnit4定义了一个新的Annotation，并相应地对已有的Runner进行扩展，使其能够解析新引入的Annotation。(2011.12.25最后更新)

本文臆造了一个示例，会在执行单元测试方法之前，自动地为单元测试方法打印日志。该示例会为JUnit定义一个新的Annotation用于指定要打印的日志内容，并对JUnit默认提供的Runner实现BlockJUnit4ClassRunner进行扩展，使其能够识别这个新的Annotation。

1. 定义Annotation
TestLogger是一个作用于方法的Annotation，它只有一个属性，用于指定日志的内容，其代码如下所示，

@Target({ ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
public @interface TestLogger {
public String log() default "";
}

2. 扩展Runner
JUnit提供了若干个Runner的实现，如BlockJUnit4ClassRunner，Suite，其中BlockJUnit4ClassRunner用来执行单个测试用例类。LoggedRunner将扩展BlockJUnit4ClassRunner，覆写其中的methodBlock()方法。新的methodBlock()方法会在一开始试图获取被执行测试方法中的TestLogger Annotation，如果存在的话，就会打印出指定的日志，每行日志以当时的执行时间与完整方法名作为前缀。该类的代码如下所示，

public class LoggedRunner extends BlockJUnit4ClassRunner {

    private static final DateFormat format = new SimpleDateFormat("yyyy-MM-dd_HH:mm:ss_SSS");

    public LoggedRunner(Class klass) throws InitializationError {
        super(klass);
    }

    @Override
    protected Statement methodBlock(FrameworkMethod method) {
        Method classMethod = method.getMethod();
        TestLogger loggerAnnotation = classMethod.getAnnotation(TestLogger.class);
        if (loggerAnnotation != null) {
            StringBuilder log = new StringBuilder(format.format(new Date()));
            log.append(" ").append(classMethod.getDeclaringClass().getName())
                    .append("#").append(classMethod.getName()).append(": ")
                    .append(loggerAnnotation.log());
            System.out.println(log.toString());
        }

        return super.methodBlock(method);
    }
}

3. 应用程序
Calculator是一个简单的应用程序，其中定义了一个除法方法，代码如下所示，

public class Calculator {

    public int divide(int a, int b) {
        return a / b;
    }
}

4. 单元测试程序
CalculatorTest是一个简单的单元测试程序，它会使用两种方式对Calculator中的divide()方法进行单元测试。其代码如下所示，

@RunWith(LoggedRunner.class)
public class CalculatorTest {

    private static Calculator calculator = null;

    @BeforeClass
    public static void createCalculator() {
        calculator = new Calculator();
    }

    @Test
    @TestLogger(log = "a simple division.")
    public void simpleDivide() {
        int value = calculator.divide(8, 2);
        Assert.assertTrue(value == 4);
    }

    @Test(expected = ArithmeticException.class)
    @TestLogger(log = "divided by zero, and an ArithmeticException thrown.")
    public void dividedByZero() {
        calculator.divide(8, 0);
    }
}

值得注意的是，CalculatorTest特别指定LoggedRunner作为测试执行器(@RunWith(LoggedRunner.class))；同时，每个单元测试方法，simpleDivide()与dividedByZero()，都使用了Annotation TestLogger，为其指定日志内容。当执行上述单元测试时，会自动地打印出如下形式的日志内容：

2011-12-13_23:48:38_218 test.CalculatorTest#simpleDivide: a simple division
2011-12-13_23:48:38_218 test.CalculatorTest#dividedByZero: divided by zero, and an ArithmeticException thrown.

5. 小结
通过对BlockJUnit4ClassRunner的扩展，可以让JUnit在运行测试用例时做一些额外的工作。但这种直接修改默认Test Runner的方式并不被提倡，在下一篇文章中将会介绍使用Test Rule来达到相同的扩展目的。

Sha Jiang 2011-12-14 00:01 发表评论

编写好的面向对象代码(译)

Sha Jiang — Tue, 07 Oct 2008 09:06:00 GMT

编写好的面向对象代码

    本文是java.net上的一篇博客，作者Curtis Cooley对编写好的面向对象代码有些建议，希望对大家都有所帮助。(2008.10.08最后更新)

获取经验没有捷径。编写好的面向对象代码需要经验，但这儿有三种做法能帮你在一开始就很顺利，即便你是老顽固：
    1. 使用测试驱动开发(TDD)编写你所有的代码
    2. 遵循简单法则
    3. 告之而非问之

使用TDD编写所有代码
    按测试先行编写的代码与按测试后行编写的代码是极为不同的代码。按测试先行编写的代码是松耦合与高聚合的。当某个属性或私有方法需要暴露给测试程序时，按测试后行编写的代码常会打破封装，因为该类并不是为了测试而设计的。如果你首先编写测试代码，你的依赖将会更好，你的代码将是松耦合与高聚合的。后面会有更多关于测试能帮助你设计更佳代码的内容。

遵循简单法则
    代码是简单的，只要当它：
    1. 执行了所有的测试
    2. 不包含重复
    3. 表达了所有的意图
    4. 使用最少的类和方法
注意到我用的是个被排序了的列表是很重要的。顺序是重要的。只有一个main()方法的的GodClass^[1]不会是简单的。这个类可能执行了所有的测试，但在任何比"Hello, world!"更复杂的程序中，它肯定包含了重复，并且也没有表达出全部的意图。
我努力使用简单法则去关注If问题。我不知道如何使用简单法则去阻止某人编写重量级的If代码。有人可能会提出不同意见，我也尝试过，但这样的重量级If代码确实无法表达意图。但当你阅读如下代码时

if (mobile.getType() == MobileTypes.STANDARD) {
alert();
}

确实难以看出其中的意图。这些代码无论处于哪个方法的上下文环境中，我们都能知道，如果mobile是STANDARD类型的话，那么就报警。而你所需要的更多意图呢？
我还有一点儿灵感显现。如果有那样的代码，那么在其它地方肯定还会有更多那样的代码。这些代码可能就像：

if (mobile.getType() == MobileTypes.GAS) {
registerGasReading();
}

和

if (mobile.getType() == MobileTypes.TEXT) {
sendTextMessage();
}

和

if (mobile.getType() == MobileTypes.LOCATION) {
notifyLocation();
}

你看出来了吗？我是看出来了。它违反了规则2，有很多地方都违反了规则2，并且是一种最坏的情形。这段代码有多处重复。重复将极难发现。所以，请帮助防止这种情形的发生，我已包含其中了。

告之而非问之
简言之，告之而非问之意指不要先问一个对象的状态，然后才让它去工作。而应该告之对象如何去工作。这就意味着之前所有的那些If例子应该变为：

mobile.alert();

和

mobile.registerGasReading();

和

mobile.sendTextMessage();

和

mobile.notifyLocation();

现假设遍布该程序中的一些If语句块有重复的实现。在"重量级If"版本的程序中，可能很难发现它们；但在"告之而非问之"版本的程序中，所有的实现都在Mobile中。所有的实现都在一处，这就便于察觉并根除问题。
倾听你的测试程序也能帮助你保持代码的简洁。

public interface Alarm {
  void alert(Mobile mobile);
}

public class Siren implements Alarm {
  public void alert(Mobile mobile) {
    if (mobile.getType == MobileTypes.STANDARD) {
      soundSiren();
    }
  }
}

public class TestSiren extends TestCase {
  public void test_alert() {
    LocationMobile mobile = new LocationMobile();
    Siren siren = new Siren();
    siren.alert(mobile);
    assert(sirenSounded());
  }
}

如果你密切地倾听测试程序，它可能会问你，"为什么你需要一个LocationMobile去测试Siren呢？"的确，为什么呢？看起来，Siren应该还不知道LocationMobile吧。

public class LocationMobile {
  private Alarm alarm;
  public LocationMobile(Alarm alarm) {
    this.alarm = alarm;
  }
  public void alert() {
    alarm.alert(); // alert on Alarm no longer needs a mobile
  }
}

public class TestLocationMobile() extends TestCase {
  public void test_alert() {
    Alarm alarm = EasyMock.createMock(Alarm.class);
    alarm.alert();
    EasyMock.replay(alarm);
    Mobile mobile = new LocationMobile(alarm);
    mobile.alert();
    EasyMock.verify(alarm);
}

好像我只是交换了依赖关系。Alarm不再依赖Mobile，现在是Mobile依赖Alarm。但如果你仔细地观察这个测试程序，你会发现真正的依赖关系是，Siren知晓了LocationMobile。一个具体类依赖另一个具体类，这违反了依赖反转原则(DIP)。第二个例子就让LocationMobile依赖Alarm接口。具体类依赖抽象，这就满足DIP了。
如果你使用TDD，并遵循简单法则和告之而非问之原则去编写所有的代码，你就处于成为一个更好的面向对象程序员的道路上了。好的面向对象代码易于阅读和维护，但难以编写，至少，在开始时是这样的。你写的越多，你就会变得越好，也会获得更多的经验。同时，这些实践经验也会使你在自己的道路上受益匪浅。

译注
[1]GodClass(上帝类)指包含了太多内容的类。

Sha Jiang 2008-10-07 17:06 发表评论

何时编写单元测试？(译)

Sha Jiang — Mon, 09 Jun 2008 12:55:00 GMT

何时编写单元测试？

    是在编写一个方法之前就编写它的单元测试，还是在写完这个方法，甚至是整个类之后才编写单元测试呢？John Ferguson Smart^[1]在他的blog中再次提出了这个问题，并根据自己的经验给出了一些建议。(2008.06.10最后更新)

    都别书生意气了。在你编写一个方法之前或是之后编写单元测试--根据我的经验，只要你在编写代码的几乎同时就考虑并编写单元测试程序，那么这就无关紧要了。过后再返回去(或者根本就不回去)写测试程序将导致问题。就我个人而言，我喜欢在编写少量代码之前或紧接着的之后就编写单元测试--这不会打破工作流程，因为它就是流程的一部分。
    这需要一点儿实践经验--缺乏经验的开发者经常为要写什么样的测试程序而烦恼。但这可能也反映出一个事实：他们同样也不知道要写什么样的代码。一些人评说TDD能够鼓励进行微设计--一种非常底层的设计，它不需要考虑较大的场景。这会发生在缺乏经验的开发者身上；如果你教条般地应用这种方法，同样也会遇上。像行为驱动开发这样的方法在此处就会很酷。当你在写getter方法之前，你会写一个针对这个getter方法的单元测试吗？如果是的话，那么你的单元测试专注的层次就较高了，也会更接近于用户(或系统)的需求。
    回到问题的本质，为什么我喜欢把单元测试放在最开始的位置？很简单！我的实践经验告诉我，那样可以帮助提高代码的质量，并且节约调试时间。在开始时写十个小的单元测试所花的时间比在以后修复Bug所花的时间要少，如果代码经过了正确的单元测试，那就不会有Bug了。
    事实上，我屡屡见到，如果某些代码经过了适当的单元测试，那么就不会有编码问题。最近就有一个例子：花了一个小时的时间去搜寻Web应用中的一个问题，该问题出现在一个编写正确的Spring-MVC程序中。结果是由于一个检验器类忽略了一个异常。很容易就发现了这个问题，实际上，在看了代码(代码检查(Code Review)也很有效)之后立刻就发现了。但关键是，我们花了一个小时甚至更多的时间去找这个需要进行检查的类。如果这些代码经过了适当的测试，那么就能很快地发现并解决这个问题。
    根据我的经验，当人们在编写完程序之后才开始编写单元测试，就如同事后才有这样的想法，他们很难写出这些测试了 ("我已经完成了所有的代码，此时我还得去写单元测试")。或者根本就不去做。在这种情况下，代码是否完成了呢？如果代码运行地很好，那就算是完成了。这样的话，再写单元测试就大大地丧失了它的价值。还不仅如此，事后编写的单元测试将是肤浅的，不会对代码进行良好地测试。或者，开发者已经耗完了时间，他们根本就不想再为单元测试伤神了。
    TDD与任何其它的编码实践一样。当你正在学习某个新的技术时，你会倾向于对学习指导亦步亦趋。类似地，当你学习一项武术时，你也会试着一步步地模仿大师的动作，而不必去理解其中的逻辑。一旦你熟悉了某个技术，能够熟练地使用它，并对它有了更深入地理解，然后，你就能改进它，并与你之前掌握的其它技术进行溶合了。

译注
[1]John是Java Power Tools一书的主作者，也是java.net中一位活跃的Blogger。

译后
    上周在java.net上看到这篇Blog，再联想到自己在平时工作中的单元测试实践，有些感触，故将其翻译了出来，与大家共享。
    事先就编写单元测试，还是事后才编写单元测试？这是一个老问题。按照TDD的思想，自然是要先编写单元测试，然后再编写能够通过该单元测试的方法。
    但，单元测试并不是TDD的专属领地，很多不实践TDD的项目也在应用着单元测试。
    我认为，在不实践TDD的项目中(我自己所处的环境就是如此)，事后编写单元测试仍有着其合理性：
    1. 以消极的态度来看，既然项目本身不严格要求事先编写单元测试，那么就可以在事后去做了。这至少比不去做要好，聊胜于无嘛。(嘿嘿，是够消极的，但也拿你没办法)
    2. 事后编写单元测试至少也是一种检验手段，当然，肯定比不上事先编写的单元测试。因为，事后编写的单元测试很可能会"将就"已经写好的应用程序，正如John所说"事后编写的单元测试将是肤浅的，不会对代码进行良好地测试"。但...仍然是聊胜于无嘛 :-D (哈哈，有完没完了)
    3. 可以把单元测试，其中就包含事后单元测试，作为"后来者"了解、学习应用程序的手段。因为单元测试程序就是应用程序的"客户"，所以无论它是事先写的，还是事后写的，都能够表现出应用程序的行为。
    4. 事后单元测试，也可能转化为事先单元测试。在应用程序的整个生命周期中，维护阶段是最长的。在"漫长"的维护过程中，"之前"所写的"事后"单元测试将会成为"后来者"(包括原始作者本人)的"事先"单元测试。在改进程序的过程中，这些单元测试仍然能起到监督的作用。(orz，有点儿诡辩)
    虽然，事后单元测试明显不如事先单元测试，但它的作用仍然不可低估。只要编写了优秀的单元测试程序，无论是在哪个阶段，它都会对改进应用程序有莫大的帮助。(这可不是"聊胜于无"能够表达的)

Sha Jiang 2008-06-09 20:55 发表评论