org.junit.rules.方法规则和org.junit.rules.TestWatchman已被弃用。
一个有趣的注意事项是:https://github.com/junit-team/junit/pull/519,部分原因是:“许多开发人员是坚持使用方法规则的正当理由,JUnit团队没有计划删除对方法规则的支持......”
http://junit-team.github.io/junit/javadoc/4.10/org/junit/rules/TestWatchman.html文档:“已弃用。MethodRule已弃用。请改用TestWatcher实现TestRule。”并提供了一些示例代码。
将这些标记为不推荐的原因是什么?TestWatcher和不推荐的TestWachman之间的权衡是什么?你有关于这个特定主题的概要或概述的好链接吗?
原因很简单,Test规则
被计划替换METODROD
。METODROD
是在4.7中引入实现的,它是一个接口,有一种方法:
Statement apply(Statement base, FrameworkMethod method, Object target)
Frameworkmethod
是(几乎)一个内部JUnit类,一开始就不应该公开。对象
是运行方法的对象,例如,您可以使用反射修改测试的状态。
然而,在4.9中引入的测试规则是:
Statement apply(Statement base, Description description)
Description
是一个不可变的POJO,包含测试的描述。在测试中修改状态的方法是使用测试规则
在测试中正确封装。这是一个完全干净的设计。
TestWatchman(MethodRule)和TestWatcher(TestRule)之间的具体差异最小,只是TestWatcher具有更好的错误处理能力,因此应优先使用。这两种方法都有可重写的方法,例如succeed()
、failed()
、start()
、finished()
。
public static class WatchmanTest {
private static String watchedLog;
@Rule
public TestWatcher watchman= new TestWatcher() {
@Override
protected void failed(Throwable e, Description description) {
watchedLog+= description + "\n";
}
@Override
protected void succeeded(Description description) {
watchedLog+= description + " " + "success!\n";
}
};
@Test
public void fails() {
fail();
}
@Test
public void succeeds() {
}
}
TestWatcher(TestRule)
处理overiden方法中的异常。如果抛出异常,则测试方法在执行测试后失败,而不是在测试期间失败。
有关更多信息,请参阅TestWatcher和TestWatchman
在Marshmallow中,已弃用android.net.SSL证书SocketFactory.getHttpSocketFactory,没有解释为什么或什么取代了它。作为一名安全工程师,我不能每天都使用Android系统,但我有开发者问我为什么以及如何使用Android系统...有人有其他信息吗?我已经用完了我的谷歌foo,但没有用。 请注意,这可能与33352067有关——这个问题的答案可能有
有人知道是什么取代了Amazon DynamoDBClient吗?在留档里什么都找不到 包-com。亚马逊。服务。发电机BV2
根据Intel在x64中的说法,以下寄存器被称为通用寄存器(RAX、RBX、RCX、RDX、RBP、RSI、RDI、RSP和R8-R15)https://software.Intel.com/en-us/articles/indroduction-to-x64-assembly。 在下面的文章中,RBP和RSP是特殊用途寄存器(RBP指向当前堆栈帧的底部,RSP指向当前堆栈帧的顶部)。https:
问题内容: 我只是好奇为什么不赞成使用HTML中的标记。 通过将容器封装在标签中,这是一种快速居中对齐文本和图像块的简单方法,我现在真的找不到任何更简单的方法。 任何人都知道关于如何使“东西”居中(而不是和宽度的东西)的任何简单方法吗?而且,为什么不推荐使用它? 问题答案: 该元素已弃用,因为它定义了其内容的 表示形式 —它未描述其内容。 居中的一种方法是将元素的和属性设置为,然后将父元素的属性设
问题内容: 我知道使用执行程序而不是ThreadGroup的当前做法: 通常首选的处理线程的方法 从线程等捕获异常… 但是,这样 的ThreadGroup 固有的 缺陷是 什么(我听过对该类的模糊批评)? 感谢您的回答。 PS。这似乎无法回答这个问题。 问题答案: 这在《有效的Java第二版》中进行了解释。,项目73。 最初将线程组设想为一种出于安全目的隔离小程序的机制。他们从来没有真正兑现过这个
我将junit的版本升级到4.11,并得到: 如何迁移,迁移到什么地方?