junit:junit_简而言之，JUnit：Hello World

junit:junit

对于Java世界中的开发人员而言， JUnit似乎是最受欢迎的测试工具。因此，难怪就此主题已经写了一些好书。但是，通过以顾问为生，我仍然经常遇到程序员，他们至多对工具及其正确用法都不了解。

因此，我想到了写几篇介绍基本技术的文章的想法。目的是提供一个合理的起点，但要避免xUnit测试模式^1带来的艰巨信息泛滥。相反，将在适当时提供指向深入文章，书籍章节或不同意见的指针，以供进一步阅读。

尽管存在有关该主题的其他文章，但本微型系列文章中采用的方法可能适合于帮助一两个开发人员熟悉JUnit测试的世界-这将使工作值得。

何必呢？

编写高质量的软件是一项艰巨的任务。至于许多其他倡导敏捷方法的人，对我而言，进行大规模的前期计划并不是一件好事。但是对于所有这些方法，当我们开始将JUnit与TDD一起使用时，我获得了最大的进步。确实，实证研究似乎证实了我的看法，即infoQ文章指出²这种做法可以提高质量 。

但是，JUnit测试并不像看起来那样琐碎。我们一开始犯的一个致命错误是将测试班视为二等公民。逐渐地，我们意识到测试不仅仅是一个简单的验证机，而且-如果编写得不当心，可能会给维护和进步带来麻烦³ 。

如今，我倾向于将测试用例更多地视为被测单元的随附规范 。与齿轮之类的工件的规格非常相似，它告诉质量检查人员该单元必须满足哪些关键指标。但是由于软件的性质，只有开发人员才能编写如此低级的规范。这样，自动化测试就成为有关单元预期行为的重要信息来源。还有一个不像文档那样容易过时的…

入门

一千英里的旅程始于一步
老子

让我们假设我们必须编写一个简单的数字范围计数器，该计数器从给定值开始传递一定数量的连续整数。遵循随附规范的隐喻，我们可以从以下代码开始：

public class NumberRangeCounterTest {
}

测试类表达了开发单位NumberRangeCounter的意图， Meszaros将其表示为被测系统（SUT）。按照通用的命名模式，单元名称由后缀Test补充。

一切都很好，但是急躁的人可能会想：下一步是什么？首先应该测试什么？而且–无论如何我如何创建可执行测试？

有多种方法可以合并JUnit。如果使用Eclipse Java IDE，则该库已包含在内。只需将其添加到项目的构建路径中，这在本教程中就足够了。要获得自己的副本，请参阅下载并安装，有关maven集成的信息，请参见《使用JUnit》；如果您碰巧需要OSGi捆绑软件，请在蚀轨道下载中查找。

通常，从Happy Path开始是个好主意， Happy Path是执行的“正常”路径，理想情况下是一般业务用例。对于SUT NumberRangeCounter这可能是一个验证测试，以确保计数器在方法的后续调用中返回连续的数字，该方法仍必须定义。

可执行的JUnit测试是一个公开的非静态方法，该方法使用@Test进行注释，并且不带任何参数。总结所有这些信息，下一步可能是以下方法存根⁴ ：

public class NumberRangeCounterTest {@Testpublic void subsequentNumber() {    }
}

仍然不多，但实际上JUnit第一次运行测试就足够了。可以从命令行或特定的UI启动JUnit测试运行，但是在本教程的范围内，我假定您具有可用的IDE集成。在Eclipse中，结果看起来像这样⁵ ：

格林巴

绿色条表示测试运行未发现任何问题。这并不奇怪，因为我们尚未进行任何测试。但是请记住，我们已经做了一些有用的考虑，可以帮助我们轻松地进行第一个测试：

我们打算编写一个NumberRangeCounter单元，该单元负责传递连续的整数值序列。为了测试它，我们可以创建一个接受此类计数器新实例的局部变量。

@Testpublic void subsequentNumber() {    NumberRangeCounter counter = new NumberRangeCounter();}

由于第一个测试应该断言NumberRangeCounter提供的数字是连续的整数值，表示5、6、7等，因此SUT可以使用提供这些值的方法。此外，可以两次调用此方法以提供最小的后续值集。

@Testpublic void subsequentNumber() {    NumberRangeCounter counter = new NumberRangeCounter();int first = counter.next();int second = counter.next();}

到目前为止看起来很合理，但是如果second的值不是first的有效后继，我们如何确保测试运行被表示为失败？为此，JUnit提供了org.junit.Assert类，该类提供了一组静态方法来帮助开发人员编写所谓的自检测试。

带有assert前缀的方法用于检查特定条件，并在否定结果上抛出AssertionError 。 JUnit运行时会拾取此类错误，并在结果报告中将测试标记为失败。

2014年8月13日更新：使用org.junit.Assert只是一种可能。 JUnit还包括一个匹配器库Hamcrest ，许多人认为它是关于干净代码的更好解决方案。我个人最喜欢名为AssertJ的第三方库的语法。

我认为Assert对于初学者而言可能更直观，因此我为“ hello world”帖子选择了Assert 。由于对该决定的评论，我意识到至少在这一点上我不得不提到其他可能性。我将在后续文章中详细介绍Hamcrest和AssertJ的用法。

要断言两个值或对象相等，可以使用Assert#assertEquals 。由于在声明方法调用中使用静态导入是很常见的，所以subsequentNumber测试可以像这样完成：

@Testpublic void subsequentNumber() {    NumberRangeCounter counter = new NumberRangeCounter();int first = counter.next();int second = counter.next();assertEquals( first + 1, second );}

如您所见，测试指定了SUT的重要行为，甚至还不存在。顺便说一句，这也意味着测试类不再编译！因此，下一步可能是创建我们部门的框架来解决此问题。

尽管本教程是关于JUnit而不是TDD的，但是我还是选择了后者的方法，以强调干净的JUnit测试用例所具有的规范字符。这种方法将工作重点从单位的内部转移到其使用和较低级别的要求上。

如果您想了解有关TDD的更多信息，特别是用于实现单个单元的“红色/绿色/重构”口头禅，可以读一读 Kent Beck的“ 示例驱动开发”或Lasse Koskela的“ 示例 驱动”一书。

下面的代码片段显示了NumberRangeCounter存根的外观：

public class NumberRangeCounter {public int next() {return 0;}
}

再次运行测试，由于NumberRangeCounter#next()实现不足，现在导致出现红条。这可以确保通过无用的验证或类似方式不会偶然满足该规范：

除红色条外，执行报告还显示总共运行了多少测试，哪些测试因错误而终止以及有多少由于错误的断言而失败。每个错误/失败的堆栈跟踪信息有助于在测试类中找到确切的位置。

AssertionError提供了一条解释性消息，该消息显示在故障跟踪的第一行中。错误测试可能表示任意编程错误，从而导致在测试的断言语句之外引发Exception 。

注意，JUnit遵循全有或全无原则。这意味着，如果一个测试运行涉及一个以上的测试（通常是这种情况），则单个测试的失败将整个执行标记为红色，表示失败。

由于对于本文主题而言，特定单元的实际实现没有多大意义，因此我将由您自己提出一个创新的解决方案，以使我们的第一个测试再次通过！

结论

前面的部分介绍了JUnit测试的基本知识–如何编写，执行和评估它。在这样做的同时，我重视这样的事实，即应该使用人们可能想到的最高编码标准来开发此类测试。给出的示例希望平衡得足够好，以提供易于理解的介绍而又不琐碎。改进建议当然受到高度赞赏。

Nutshell文章中的下一个JUnit将继续该示例，并涵盖测试用例的一般概念及其四个阶段的测试结构，请继续关注。

不要误会我的意思-我非常喜欢这本书，但是通用方法可能不是入门的最佳方法：xUnit测试模式， Gerard Meszaros ，2007年
其他研究在http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment上列出，对实证研究的比较分析可在https://tuhat.halvi.helsinki.fi/portal/files/29553974/2014_01_swqd_author_version.pdf上找到。
另请参阅：保持测试整洁，干净的代码，第9章， Robert C. Martin， 2009年
关于如何命名测试方法的观点存在分歧。我已经在正确获取JUnit测试名称中写下了有关此主题的一些注意事项
有关如何在Eclipse中使用JUnit的更多信息，您可能想阅读我的文章《在Eclipse中高效使用JUnit》