《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。

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