做网站的作品思路及步骤,旅游网站建设的原因,网站定制开发合同,合肥seo排名收费尽管存在关于JUnit测试的书籍和文章#xff0c;但我仍然经常遇到程序员#xff0c;他们至多对这个工具及其正确用法都不甚了解。 因此#xff0c;我想到了编写多部分教程的想法#xff0c;从我的角度解释了要点。 也许在这个小型系列中采用的动手方法可能适合使一两个额外… 尽管存在关于JUnit测试的书籍和文章但我仍然经常遇到程序员他们至多对这个工具及其正确用法都不甚了解。 因此我想到了编写多部分教程的想法从我的角度解释了要点。 也许在这个小型系列中采用的动手方法可能适合使一两个额外的开发人员对单元测试感兴趣这将使工作值得。 上次我介绍了测试的基本知识–测试的编写执行和评估方式。 在这样做的同时我概述了测试不仅仅是一个简单的验证机而且还可以用作一种低级规范。 因此应该以人们可能想到的最高编码标准来开发它。 这篇文章将继续本教程的示例并使用Meszaros在xUnit Test Patterns [MES]中定义的命名法得出表征良好编写的单元测试的通用结构。 测试的四个阶段 整洁的房子整洁的头脑 老格言 本教程的示例是关于编写一个简单的数字范围计数器该计数器从给定值开始提供一定数量的连续整数。 从快乐的路径开始最后一个帖子的结果是一个测试该测试已验证 NumberRangeCounter在后续调用next方法时返回连续数字 Testpublic void subsequentNumber() { NumberRangeCounter counter new NumberRangeCounter();int first counter.next();int second counter.next();assertEquals( first 1, second );} 请注意本章将坚持使用JUnit内置功能进行验证。 我将在另一篇文章中介绍特定匹配器库 Hamcrest AssertJ 的优缺点。 细心的读者可能已经注意到我使用空行将测试分为不同的部分并且可能想知道为什么。 为了回答这个问题让我们更仔细地研究三个部分 第一个创建要测试的对象的实例称为SUT 被测系统。 通常本节在进行任何与测试相关的活动之前会确定SUT的状态。 由于此状态构成了定义良好的测试输入因此也称为测试夹具 。 建立固定装置后就该调用SUT的那些方法了 这些方法代表测试要验证的某种行为。 通常这只是一个方法结果存储在局部变量中。 测试的最后一部分负责验证是否已获得给定行为的预期结果。 尽管有一种思想流传着“每次测试一个声明”的策略但是我更喜欢“ 每次测试一个概念”的想法这意味着本节不仅仅局限于一个断言因为它恰好在示例中[MAR1]。 这种测试结构非常普遍并已被多位作者描述。 它被标记为排列执行声明 [KAC] –或构建操作检查 [MAR2] –模式。 但是对于本教程我想精确一点并坚持使用Meszaros的[MES]这四个阶段分别是 设置1练习2验证3和拆卸4 。 拆卸阶段是为了在长期存在的情况下清理灯具。 持久表示夹具或夹具的一部分将在测试结束后继续存在并且可能对其后继产品的结果产生不良影响。 普通单元测试很少使用持久性夹具因此拆卸阶段如我们的示例所示通常被省略。 而且由于它与规范角度完全不相关因此无论如何我们都希望将其排除在测试方法之外。 一分钟内将介绍如何实现此目的。 由于这篇文章的范围我避免了单元测试的精确定义。 但是我坚持Tomek Kaczanowski在使用JUnit和Mockito进行实用单元测试中描述的三种类型的开发人员测试 可以概括为 单元测试可确保您的代码正常运行并且必须经常运行因此运行速度非常快。 基本上这就是本教程的全部内容。 集成测试关注于不同模块的正确集成包括开发人员无法控制的代码。 这通常需要一些资源例如数据库文件系统因此测试运行速度较慢。 端到端测试从客户端的角度验证您的代码是否有效并将系统作为一个整体进行测试以模仿用户的使用方式。 他们通常需要大量时间才能执行自己。 对于如何有效地组合这些测试类型的深入示例您可以看看Steve Freeman和Nat Pryce的 Tests指导的Growinging Oriented Oriented Software 。 但是在继续进行示例之前还有一个问题需要讨论 为什么这很重要 阅读代码与写作所花费的时间比例远远超过101… 罗伯特·马丁 四个阶段模式的目的是使您易于理解测试正在验证的行为。 安装程序始终定义测试的前提条件练习实际上会调用测试的行为验证是否指定了预期的结果而拆除工作完全与内部维护有关正如Meszaros所说的那样。 这种干净的相分离清楚地表明了单个测试的意图并提高了可读性。 该方法意味着测试一次只能验证给定输入状态的一种行为因此通常没有条件块等单条件测试。 试图避免繁琐的夹具安装并在单一方法中测试尽可能多的功能虽然很诱人但这通常会导致某种性质的混淆 。 因此请始终记住如果不小心编写测试可能会给维护和进步带来痛苦。 但是现在是时候继续进行示例了看看这种新知识可以为我们做什么 角落案例测试 完成快乐路径测试后我们将继续指定极端情况行为。 对数字范围计数器的描述指出数字序列应从给定值开始。 这一点很重要因为它定义了计数器范围的下限一个角…。 将该值作为配置参数传递给NumberRangeCounter的构造函数似乎很合理。 适当的测试可以验证next返回的第一个数字是否等于此初始化 Testpublic void lowerBound() {NumberRangeCounter counter new NumberRangeCounter( 1000 );int actual counter.next();assertEquals( 1000, actual );} 再次我们的测试类不会编译。 通过将lowerBound参数引入计数器的构造函数来解决此问题则会在subsequentNumber测试中导致编译错误。 幸运的是后一个测试被编写为独立于下限定义因此该测试的夹具也可以使用该参数。 但是测试中的原义数字是多余的没有明确指出其目的。 后者通常表示为幻数 。 为了改善这种情况我们可以引入一个常量LOWER_BOUND并替换所有文字值。 以下是测试类的外观 public class NumberRangeCounterTest {private static final int LOWER_BOUND 1000;Testpublic void subsequentNumber() {NumberRangeCounter counter new NumberRangeCounter( LOWER_BOUND );int first counter.next();int second counter.next();assertEquals( first 1, second );}Testpublic void lowerBound() {NumberRangeCounter counter new NumberRangeCounter( LOWER_BOUND );int actual counter.next();assertEquals( LOWER_BOUND, actual );}
} 查看代码您可能会注意到夹具的在线设置对于两种测试都是相同的。 通常内联设置由多个语句组成但是测试之间通常存在共同点。 为了避免冗余可以将共同之处委托给设置方法 public class NumberRangeCounterTest {private static final int LOWER_BOUND 1000;Testpublic void subsequentNumber() {NumberRangeCounter counter setUp();int first counter.next();int second counter.next();assertEquals( first 1, second );}Testpublic void lowerBound() {NumberRangeCounter counter setUp();int actual counter.next();assertEquals( LOWER_BOUND, actual );}private NumberRangeCounter setUp() {return new NumberRangeCounter( LOWER_BOUND );}
} 如果委托设置方法可以提高给定情况下的可读性这是有争议的但它会导致JUnit的一个有趣功能 隐式执行公共测试设置的可能性。 这可以通过将Before注释应用于不带返回值和参数的公共非静态方法来实现。 这意味着此功能需要付出一定的代价。 如果要消除测试中的多余setUp调用则必须引入一个采用NumberRangeCounter实例的字段 public class NumberRangeCounterTest {private static final int LOWER_BOUND 1000;private NumberRangeCounter counter;Beforepublic void setUp() {counter new NumberRangeCounter( LOWER_BOUND );}Testpublic void subsequentNumber() {int first counter.next();int second counter.next();assertEquals( first 1, second );}Testpublic void lowerBound() {int actual counter.next();assertEquals( LOWER_BOUND, actual );}
} 显而易见 隐式设置可以消除很多代码重复。 但是从测试的角度来看它也引入了一种魔术这会使阅读变得困难。 因此对于“我应该使用哪种安装类型”这个问题答案很明确。 是这取决于… 由于我通常会注意保持单位/测试较小因此折衷似乎可以接受。 因此我经常使用隐式设置来定义公共/快乐路径输入并为每个极端案例测试通过小的内联/代理设置对它进行相应的补充。 否则由于特别是初学者倾向于让测试变得更大因此最好坚持使用内联和委托设置。 JUnit运行时确保在测试类的新实例上调用每个测试。 这意味着在我们的示例中仅构造函数的灯具可以完全省略setUp方法。 可以通过隐式方式为counter字段分配新的 fixture private NumberRangeCounter counter new NumberRangeCounter( LOWER_BOUND ); 尽管有些人Before使用它但其他人则认为Before注释方法会使意图更加明确。 好吧我不会就此进行战争让您自己决定的决定…… 隐式拆解 想象一下无论出于何种原因都需要处理NumberRangeCounter 。 这意味着我们必须在测试中添加拆卸阶段。 根据我们的最新代码片段使用JUnit可以轻松实现因为它支持使用After注释进行隐式拆卸 。 我们只需要添加以下方法 Afterpublic void tearDown() {counter.dispose();} 如上所述拆卸完全是关于客房清洁的完全不对特定测试添加任何信息。 因此隐式执行此操作通常很方便。 或者即使测试失败也必须使用try-finally构造来处理此问题以确保执行拆解。 但是后者通常不会提高可读性。 预期的例外 一个特殊的极端情况是测试预期的异常。 出于示例考虑如果next的调用超出给定范围的值量则NumberRangeCalculator应该引发IllegalStateException 。 同样通过构造函数参数配置范围可能是合理的。 使用try-catch构造我们可以编写 Testpublic void exeedsRange() {NumberRangeCounter counter new NumberRangeCounter( LOWER_BOUND, 0 );try {counter.next();fail();} catch( IllegalStateException expected ) {}} 好吧这看起来有些丑陋因为它模糊了测试阶段的分离并且可读性不强。 但是由于Assert.fail()会引发AssertionError因此可以确保在没有引发异常的情况下测试失败。 并且catch块可以确保在抛出预期异常的情况下成功完成测试。 使用Java 8可以使用lambda表达式编写结构清晰的异常测试。 有关更多信息请参阅 使用Java 8 Lambdas清洁JUnit Throwable-Tests 。 如果足以验证是否已抛出某种类型的异常则JUnit通过Test批注的expected方法提供隐式验证 。 上面的测试可以写成 Test( expected IllegalStateException.class )public void exeedsRange() {new NumberRangeCounter( LOWER_BOUND, ZERO_RANGE ).next();} 尽管此方法非常紧凑但也很危险。 这是因为不能区分是在设置的建立阶段还是在测试的执行阶段抛出了给定的异常。 因此如果构造函数意外IllegalStateException则测试将是绿色的因此毫无价值。 JUnit提供了第三种可能性可以更清晰地测试预期异常即ExpectedException规则。 由于我们还没有涵盖规则 并且该方法有点扭曲了四个阶段的结构因此我将对该主题的明确讨论推迟到有关规则和运行者的后续文章上并且仅提供摘要作为预告片 public class NumberRangeCounterTest {private static final int LOWER_BOUND 1000; Rulepublic ExpectedException thrown ExpectedException.none();Testpublic void exeedsRange() {thrown.expect( IllegalStateException.class );new NumberRangeCounter( LOWER_BOUND, 0 ).next();}[...]
} 但是如果您不想等待可以在RafałBorowiec的 《 JUNIT EXPECTEDEXCEPTION RULEBEYOND BASICS 》一文中详细了解一下。 结论 简而言之JUnit的这一章解释了通常用于编写单元测试的四个阶段结构-设置练习验证和拆卸。 它描述了每个阶段的目的并着重强调了在一致使用时如何提高测试用例的可读性。 该示例在极端案例测试的上下文中加深了该学习材料。 希望它具有足够的平衡性可以提供容易理解的介绍而又不琐碎。 改进建议当然受到高度赞赏。 本教程的下一章将继续该示例并介绍如何处理单元依赖性和测试隔离敬请关注。 参考文献 [MES] xUnit测试模式第19章四阶段测试Gerard Meszaros2007年 [MAR1]清洁规范第9章单元测试第130页及以下Robert C. Martin2009年 [KAC]使用JUnit和Mockito进行的实用单元测试3.9。 单元测试的阶段Tomek Kaczanowski2013年 [MAR2]清洁代码第9章单元测试第127页Robert C. Martin2009年 翻译自: https://www.javacodegeeks.com/2014/08/junit-in-a-nutshell-test-structure.html
