测试驱动开发 测试前移_如何开始测试驱动的开发

测试驱动开发 测试前移

经常转向测试驱动开发（TDD）的软件开发人员经常联系我。 他们了解，首先描述期望，然后编写满足这些期望的代码是编写软件的最佳方法。 他们同意，首先编写测试不会带来任何开销，因为他们无论如何都必须编写测试。 但是，他们仍然陷入困境，不清楚要测试什么，何时进行测试以及如何进行测试。 本文将回答这些问题。

首先，比喻

假设您正在一个被要求制造赛车的团队中工作。 目标是提供一种产品，使乘员能够将汽车从一个城市（例如俄勒冈州波特兰）驾驶到另一个城市（例如华盛顿州西雅图）。

您的团队可以通过几种不同的方式来设计和制造汽车。 一种方法是手工制作一个独特的整体式车辆，其中所有零件都是本地生产并紧密耦合的。 另一种方法是仅使用预制零件并将它们缝合在一起。 这两种极端方法还有许多其他排列。

假设您的团队需要手工构建赛车的组成部分。 汽车需要电池才能运行。 为了进行类比，请重点关注定制的汽车电池。 您将如何进行测试？

测试策略

测试定制汽车电池的一种方法是雇用测试人员，将装有电池的汽车运送到波特兰，然后让测试人员将汽车从波特兰开到西雅图。 如果汽车到达西雅图，则可以确认是，汽车电池可以正常工作。

测试定制汽车电池的另一种方法是将其安装在汽车中，并查看发动机是否翻转。 如果引擎启动，则可以确认是，汽车电池可以正常工作。

还有一种方法是使用电压表并连接正极（+）和负极（-）端子，以查看电压表是否记录了12.6至14.7伏范围内的电压输出。 如果是这样，您可以确认是的，汽车电池可以正常工作。

以上三个假设示例说明了测试汽车电池的不同方法与三种测试策略如何匹配：

1. 雇用测试人员将汽车从波特兰驾驶到西雅图符合系统或端到端测试策略 。
2. 将电池安装在汽车中并验证发动机是否启动符合集成测试策略 。
3. 测量汽车电池的电压输出以验证其是否在预期范围内，符合单元测试策略 。

TDD与单元测试有关

我希望这些示例为区分单元测试，集成测试和系统端到端测试提供简单的指导原则。

牢记这些准则，在您的TDD实践中切勿包含集成或系统测试，这一点非常重要。 在TDD中，预期结果始终是微观结果。 测量汽车电池的电压输出是微结果的一个很好的例子。 汽车电池是一个功能单元，不能轻易分解为几个较小的功能单元。 因此，它是编写单元测试（即描述预期的可测量输出）的理想选择。

您还可以用以下形式写出对期望的描述：“我希望汽车发动机在转动钥匙时启动。” 但是，该描述不符合单元测试的条件。 为什么？ 因为汽车的粒度不够低。 按照软件工程的说法，汽车没有体现单一责任原则 （SRP）。

当然，虽然您也可以用以下形式写出您的期望描述：“我希望这辆从波特兰开始旅程的汽车会在x个小时后到达西雅图，”但该描述并不符合单元测试。 从波特兰到西雅图的汽车旅行的许多方面都可以测量，所以这种端到端的描述绝不应该是TDD的一部分。

模拟真实条件

这就是单元测试简单的优点。 它易于模拟，易于测量，易于离开练习，并确信所有操作均按预期进行。

那么，什么才是造成这种魔力的原因？ 答案很简单- 没有依赖关系 。 汽车电池不依赖与汽车有关的任何东西。 它也不依赖于与从波特兰到西雅图的公路旅行有关的任何事情。 请记住，随着您分解后的系统组件越来越不依赖其他组件，您的解决方案将变得越来越可靠。

结论

软件工程的艺术包括将复杂的系统分解成小的组成元素的能力。 每个单独的元素必须减小到最小的表面。 一旦在分解系统的过程中达到了这一点，就可以很容易地将注意力集中在描述对每个单元的输出的期望上。 您可以通过遵循一种形式化的模式来做到这一点，在该模式中，您首先描述先决条件 （即，假定存在这样的值）， 动作 （即，假定这样的事件到来）以及结果或后置条件 （即，您期望某某值可以测量）。

翻译自: https://opensource.com/article/20/1/test-driven-development

测试驱动开发 测试前移