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

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

Gradle从0入门到实战系列【八】SpringBoot集成Junit单元测试 JUnit 是一个 Java 编程语言的单元测试框架。JUnit 在测试驱动的开发方面有很重要的发展,是起源于 JUnit 的一个统称为 xUnit 的单元测试框架之一。
《JUnit实战（第2版）》—— 导读 作为一个屡获殊荣的数学家，我无法容忍平庸。这就是数学所教给我的─不要停止，直到你把它完成，并且不仅要用好的方法，而且要用最好的方法。
《JUnit实战（第2版）》—— 2.4 用Suite来组合测试 当然，如果你想在Java环境中组织你的测试，而不依赖于你的构件系统能力，那么JUnit的Suite是非常有用的。因为一般情况下构建系统都是由专门的人员或者团队来维护，而不是开发者自己。同样，你可能不希望依赖于任何指定的IDE以及它的JUnit集成能力。
异步社区 异步社区(www.epubit.com)是人民邮电出版社旗下IT专业图书旗舰社区，也是国内领先的IT专业图书社区，致力于优质学习内容的出版和分享，实现了纸书电子书的同步上架，于2015年8月上线运营。公众号【异步图书】，每日赠送异步新书。