单元测试，测试驱动开发答案

【问题标题】：Unit Test, Test Driven Development [closed]单元测试，测试驱动开发
【发布时间】：2011-12-12 08:50:34
【问题描述】：

我与我的同事就单元测试和测试驱动开发进行了辩论。题目如下：

1) 在编写功能代码之前编写单元测试并不构成测试驱动开发方法

我认为编写单元测试确实构成了测试驱动开发，它是 TDD 的一部分。

2) 一套单元测试只是 TDD 的副产品。

一套单元测试不是 TDD 的副产品。

你说什么？

【问题讨论】：

【解决方案1】：

1) 在编写功能代码之前编写测试是必要进行TDD，但它本身并不构成TDD，至少根据经典定义，重点是进行测试pass 是设计的驱动力（而不是一些正式的设计文档）。

2) 同样，经典观点认为，重要的一点是设计从测试演变而来，迫使它非常模块化。它是（或曾经是）一个新概念，测试可以（并且应该）影响设计，并且可能经常被拒绝或忽视，因此 TDD 支持者开始觉得需要强调它。但是说测试本身“只是一个副产品”是 IMO 适得其反的夸张。

【讨论】：

谢谢。您能否详细说明为什么单元测试不构成测试驱动开发？
@Pingpong：正如我所写：TDD 意味着设计应该受到测试的影响。如果您在编写测试之前完成设计，那么即使您在开始实现设计之前编写它们，您也不是在执行经典的 TDD。
谢谢。请问换个方式，我使用单元测试工具来进行TDD。例如。通过使用 NUnit 在 Red、Green、Refactor 循环中首先编写测试代码。因此，单元测试似乎是 TDD 的一部分。
@PingPong - 一部分，但不是全部：必要但不充分。

【解决方案2】：

在编写功能代码之前编写单元测试是 TDD 的重点。所以单元测试套件不是副产品，它是核心。

测试驱动开发 (TDD) 是一种依赖于重复非常短的开发周期的软件开发过程：首先，开发人员编写一个失败的自动化测试用例，定义所需的改进或新功能，然后生成要通过的代码该测试并最终将新代码重构为可接受的标准

【讨论】：

同意。如果测试套件真的是副产品，那么您可以随时将它们拿走，并继续您的 TDD。但是你不能把它们拿走，因为重构步骤需要它们。因此，在取消测试后开发的任何新功能都将首先进行测试，而不是测试驱动。

【解决方案3】：

TDD 就是关于红 - 绿 - 重构。

如果您在测试之前有代码，则没有红色，这很糟糕，因为您的测试中可能有错误或测试其他东西，然后您认为自己正在测试并从一开始就获得绿色。只有在添加了经过该测试测试的代码后，您才应该是 Red，然后才转到 Green。

【讨论】：

【解决方案4】：

这真的取决于你的测试做什么。

就我而言，TDD 意味着代码类、属性和方法是由于首先为它们编写测试而创建的。事实上，一些开发工具允许您直接从测试屏幕创建代码存根。

为您已经创建的类中的方法编写单元测试不是 TDD。编写代码以使您的测试用例通过是。

与标准单元测试相比，TDD 将为您提供更大的测试覆盖率。它还将您的想法集中在代码的需求上，尽管根据定义生成产品似乎需要更长的时间，但在构建时或多或少都经过了全面测试。

最后你总会得到一套单元测试。

但是，必须采取务实的方法来确定您在这方面能走多远，因为众所周知，某些领域在 TDD 环境中难以实现，例如带有 javascript 的 WPF MVVM 样式视图或网页。

【讨论】：