《JUnit实战(第2版)》—第1章1.3节理解单元测试框架-阿里云开发者社区

开发者社区> 开发与运维> 正文

《JUnit实战(第2版)》—第1章1.3节理解单元测试框架

简介:

本节书摘来自异步社区《JUnit实战(第2版)》一书中的第1章1.3节理解单元测试框架,作者【美】Petar Tahchiev , Felipe Leme , Vincent Massol , Gary Gregory,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 理解单元测试框架
JUnit实战(第2版)
单元测试框架应该遵循以下几条最佳实践规则。CalculatorTest程序中一些不起眼的改进就突出体现了所有单元测试框架应该遵循(按照我们的经验)的三大规则:

每个单元测试都必须独立于其他所有单元测试而运行;
框架应该以单个测试为单位来检测和报告错误;
应该易于定义要运行哪些单元测试。
“稍好一点”的CalculatorTest程序虽然向以上规则靠拢了,但仍然存在着不足。例如,为了使每个单元测试能够真正独立运行,就应该在不同的类实例中运行它们,理想的情况是在不同的类加载器(class loader)实例中运行它们。

我们现在能够通过增加一个新的方法并且在main中增加一个对应的try/catch块来增加新的单元测试。显然,这是一个进步,但是在真正的单元测试集中,这样做还远远不够。经验告诉我们,很大的try/catch块会带来诸多维护问题。我们很可能遗漏一个单元测试并且还对此毫无意识!

如果我们可以增加新的测试方法并继续正常工作,那真是太好了。但是,程序又是如何知道要运行哪些方法呢?好吧,我们应该有一个简单的注册过程。一个注册方法至少可以盘点哪些测试正在运行。

另一种方法是使用Java的reflection和introspection功能。程序可以检查自身并决定要运行任何遵循某种命名协定的方法,例如,以“test”开头的方法。

对于单元测试框架而言,使增加测试变得更加简单(上文中提到的第3条规则)听起来像是另一条不错的规则。为了满足这条规则(通过注册或自我检测),还需要编写大量的支持代码,但这将是值得的。虽然起初的工作量会很大,但是随着每次我们增加一个新的测试,所有的努力都会得到回报。

令人高兴的是,JUnit团队为我们解决了这个麻烦。JUnit框架已经支持自我检测方法。它也支持针对每个测试使用不同的类实例和类加载器实例,并逐个报告每个测试的所有错误。既然你已经明白了你为什么要需要一个单元测试框架,那么就让我们进一步来了解JUnit。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

版权声明:本文首发在云栖社区,遵循云栖社区版权声明:本文内容由互联网用户自发贡献,版权归用户作者所有,云栖社区不为本文内容承担相关法律责任。云栖社区已升级为阿里云开发者社区。如果您发现本文中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,阿里云开发者社区将协助删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章