测试驱动开发 测试前移_走向测试驱动开发理论

测试驱动开发 测试前移

这篇文章探讨了我们对测试驱动开发（TDD）的实践的真正理解程度。

红色，绿色，重构

到目前为止，我们都知道测试驱动开发 （TDD）遵循由以下步骤组成的简单循环：

1. 首先编写一个测试。 由于没有代码，它将失败（红色）
2. 编写足够的代码以使测试通过（绿色）
3. 清理代码（重构）

这种划分的美妙之处在于我们可以一次专注于一件事。

指定，转换，重构

尽管很简单，但TDD并不容易。 为了良好地执行TDD周期，我们需要加深了解 ，我们只能从经验中获得经验 。

例如，在进行TDD一段时间后，我们可以将这些步骤视为：

1. 指定新的必需功能
2. 在保持设计不变的同时改进功能
3. 在保持功能不变的同时改进设计

当我们从这个角度看待TDD周期时，我们看到绿色阶段和重构阶段彼此相反。

重构和转换

在重构阶段，我们使用Martin Fowler的重构来清理代码。

重构是对代码的标准更改，这些更改会更改其内部结构而不更改其外部行为。 现在，如果绿色阶段和重构阶段彼此相反，那么您可能会认为也存在“相反的重构”。 你说的没错。 罗伯特·马丁 （ Robert Martin ）的转换是对代码的标准更改，可以更改其外部行为而无需更改其内部结构。

自动转换？

我们大多数人使用功能强大的IDE编写代码。 这些IDE支持重构，这意味着它们可以以确保安全的方式为您进行代码更改。 那么，我们需要类似的东西进行转换吗？ 我觉得不是。 就代码的更改而言，某些转换是如此简单，以至于实际上并不会节省任何使它们自动化的工作。 例如，我认为没有很大的空间可以改善从if到while的更改。

其他转换仅具有未指定的作用。 例如，您将如何自动执行statement->statements转换？

问题的关键在于，重构使外部行为保持相同，并且依赖于该工具来正确实现重构。 但是，转换不会共享该属性。

标准化工作

在TDD的“指定/转换/重构”视图中，我们通过在添加测试，应用转换和应用重构之间交替来编写程序。 换句话说，如果我们通过一系列差异查看非测试代码的演变，那么每个差异都将显示转换或重构。 看来我们正在接近标准化工作的精益原则。 但是，仍然缺少对“红色/指定”阶段的更深入的了解。

如何编写测试

Red / Specify阶段的必要部分显然是编写测试。 但是我们该怎么做呢？ 首先，我们如何选择要实施的下一个测试？

对于给定的要求，几乎总是有不止一个测试要编写。 引入测试的顺序对实现产生了影响 。 但是，关于如何选择下一个测试的建议很少，因此非常需要此建议。

肯特·贝克（Kent Beck）拥有一个用于测试测试顺序的方法 ，有助于获得理解。 但是，这与像重构一样的发达理论相去甚远。 所以你怎么看？ 如果我们更好地理解了这个阶段，我们是否可以提出与转换和重构等效的测试编写？

参考： 安全软件开发博客上来自我们JCG合作伙伴 Remon Sinnema 的测试驱动开发理论 。

翻译自: https://www.javacodegeeks.com/2013/01/towards-a-theory-of-test-driven-development.html

测试驱动开发 测试前移