测试驱动开发测试前移_测试驱动开发的最佳实践

<div class="field-item even" style="font-size: 16px;">
测试驱动开发测试前移
 在我以前的<a href="https://opensource.com/users/alex-bunardzic">测试驱动开发（TDD）和突变测试系列中</a> ，我演示了在构建解决方案时依靠示例的好处。这就引出一个问题：“依靠例子”是什么意思？ 
 在该系列中，我描述了构建解决方案以确定白天还是晚上时的期望之一。我提供了一个示例，其中列出了我认为属于白天类别的特定时段。我创建了一个名为dayHour的DateTime变量，并给它指定了2019年8月8日，7小时0分钟0秒的特定值。 
 我的逻辑（或推理方式）是：“当通知系统时间是2019年8月8日上午7点时，我希望系统将执行必要的计算并返回值Daylight 。” 
 有了这样一个特定的示例，创建单元测试（ Given7amReturnDaylight ）非常容易。然后，我运行测试并观察我的单元测试失败，这为我提供了修复此早期失败的机会。 
<h2 id="iteration-is-the-solution"> 迭代就是解决方案 </h2>
 TDD（以及代理，敏捷性）的一个非常重要的方面是，除非您进行迭代，否则不可能获得可接受的解决方案。 TDD是基于无休止的迭代过程的专业学科。重要的是要注意，它要求每次迭代必须以微故障开始。这种微故障只有一个目的：立即征求反馈。即时的反馈确保我们能够Swift缩小寻求解决方案与获得解决方案之间的差距。 
 冲洗，重复，直到我们完全消除差距并提供完全符合期望的解决方案为止（但请记住，期望也必须是微观期望）。 
<h2 id="why-micro"> 为什么微？ </h2>
 这种方法通常感觉很雄心勃勃。在TDD（和敏捷）中，最好选择一个微小的，几乎是微不足道的挑战，然后通过先失败然后进行迭代直到我们解决这个微不足道的挑战来进行TDD歌舞。习惯了更丰富，更精通的工程和解决问题的人往往会觉得这样的练习低于他们的能力水平。 
 敏捷哲学的基石之一是将问题空间缩小到多个最小的可能表面积。正如罗伯特·C·马丁（Robert C. Martin）所说： 
<blockquote>
 “敏捷是关于小型编程团队做小事情的小问题的一个小主意” 
</blockquote>
 但是，如何制造一系列令人印象深刻的行人，微小的，几乎微不足道的微型胜利，才能使我们达到大规模的解决方案呢？ 
 在这里，复杂而精巧的系统思维开始发挥作用。在构建系统时，总是存在以可怕的“整体”结束的风险。整体是基于紧密耦合原理构建的系统。整体的任何部分都高度依赖于同一整体的许多其他部分。这种布置使得整料非常脆弱，不可靠并且难以操作，维护，故障排除和固定。 
 避免此陷阱的唯一方法是最小化或更好地完全消除耦合。与其投入大量的精力来构建将要组装到系统中的精致零件，不如花些谦虚的步伐来构建微型零件。这些微型零件本身仅具有很小的能力，并且由于这种布置，将不依赖于其他组件。这将最小化甚至消除任何耦合。 
 构建有用的，精致的系统所需的最终结果是由一组通用的，完全独立的组件组成。每个组件越通用，结果系统将越强大，更具弹性和灵活性。同样，拥有通用组件的集合使它们能够通过重新配置这些组件而重新用于构建全新的系统。 
 考虑由乐高积木制成的玩具城堡。如果我们从城堡中挑出几乎所有街区并单独进行检查，那么我们将无法在该街区找到任何东西来指定它是用于建造城堡的乐高积木。积木本身具有足够的通用性，因此适合建造其他设备，例如玩具车，玩具飞机，玩具船等。这就是拥有通用组件的力量。 
 TDD是提供通用，独立和自主组件的可靠实践，可以安全地组装大型复杂系统。与敏捷一样，TDD专注于微活动。而且由于敏捷基于称为“整个团队”的基本原则，因此在说明业务示例时，此处说明的谦虚方法也很重要。如果用于构建组件的示例不适当，则将很难满足期望。因此，期望必须谦虚，这使得得到的例子同样谦虚。 
 例如，如果整个团队的成员（请求者）为开发人员提供了期望，并且示例显示为&#xff1a

测试驱动开发 测试前移_测试驱动开发的最佳实践

浏览过的版块

测试驱动开发测试前移_测试驱动开发的最佳实践