手机网站模板建站,个人网站备案怎么写,微信公众号h5网站开发,网站如何做营销对于Java世界中的开发人员而言#xff0c; JUnit似乎是最受欢迎的测试工具 。 因此#xff0c;难怪就此主题已经写了一些好书 。 但是#xff0c;通过以顾问为生#xff0c;我仍然经常遇到程序员#xff0c;他们至多对工具及其正确用法都不了解。 因此#xff0c;我想到… 对于Java世界中的开发人员而言 JUnit似乎是最受欢迎的测试工具 。 因此难怪就此主题已经写了一些好书 。 但是通过以顾问为生我仍然经常遇到程序员他们至多对工具及其正确用法都不了解。 因此我想到了写几篇介绍基本技术的文章的想法。 目的是提供一个合理的起点但要避免令人生畏的信息泛滥xUnit测试模式1 。 相反将在适当时提供指向深入文章书籍章节或不同意见的指针以便进一步阅读。 尽管存在有关该主题的其他文章但本微型系列文章中采用的方法可能适合帮助一两个开发人员熟悉JUnit测试的世界-这将使工作值得。 何必呢 编写高质量的软件是一项艰巨的任务。 至于其他许多倡导敏捷方法的人对我而言进行大规模的前期计划并不可行。 但是就所有这些方法而言当我们开始将JUnit与TDD一起使用时我获得了最大的进步。 确实实证研究似乎证实了我的看法正如infoQ文章所述2 这种做法可以提高质量 。 但是JUnit测试并不像看起来那样琐碎。 我们一开始犯的一个致命错误是将测试班视为第二等公民。 逐渐地我们意识到测试不仅仅是一个简单的验证机而且-如果编写得不当心可能会给维护和进步带来麻烦3 。 如今我倾向于将测试用例更多地视为被测单元的随附规范 。 与齿轮之类的工件的规格非常相似它告诉质量检查人员该单元必须满足哪些关键指标。 但是由于软件的性质只有开发人员才能编写如此低级的规范。 这样自动化测试就成为有关单元预期行为的重要信息来源。 还有一个不像文档那样容易过时的… 入门 一千英里的旅程始于一步 老子 让我们假设我们必须编写一个简单的数字范围计数器该计数器从给定值开始传递一定数量的连续整数。 遵循随附规范的隐喻我们可以从以下代码开始 public class NumberRangeCounterTest {
} 测试类表达了开发单位NumberRangeCounter的意图 Meszaros将其表示为被测系统 SUT。 按照通用的命名模式单元名称由后缀Test补充。 一切都很好但是急躁的人可能会想下一步是什么 首先应该测试什么 而且–无论如何我如何创建可执行测试 有多种方法可以合并JUnit。 如果您使用Eclipse Java IDE则该库已包含在内。 只需将其添加到项目的构建路径中这在本教程中就足够了。 要获得自己的副本请参阅下载并安装 有关maven集成的信息请参见《 使用JUnit》 如果您碰巧需要OSGi捆绑软件请在月食轨道下载中查找。 通常从Happy Path开始是个好主意 Happy Path是执行的“正常”路径理想情况下是一般业务用例。 对于SUT NumberRangeCounter这可能是一个验证测试以确保计数器在方法的后续调用中返回连续的数字该方法仍必须定义。 可执行的JUnit测试是一个公开的非静态方法该方法使用Test进行注释并且不带任何参数。 总结所有这些信息下一步可能是以下方法存根4 public class NumberRangeCounterTest {Testpublic void subsequentNumber() { }
} 仍然不多但实际上JUnit第一次运行测试就足够了。 可以从命令行或特定的UI启动JUnit测试运行但是在本教程的范围内我假定您具有可用的IDE集成。 在Eclipse中结果看起来像这样5 绿色条表示测试运行未发现任何问题。 这并不奇怪因为我们还没有测试任何东西。 但是请记住我们已经做了一些有用的考虑可以帮助我们轻松地进行第一个测试 我们打算编写一个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”帖子选择它。 由于对该决定的评论我意识到至少在这一点上我不得不提到其他可能性。 我将在后续文章中详细介绍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》 翻译自: https://www.javacodegeeks.com/2014/08/junit-in-a-nutshell-hello-world.html
