单元测试，测试驱动开发[已关闭]

Question

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

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

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

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

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

你说什么？

Answer 1

1）在编写功能代码之前编写测试是进行 TDD 的“必要条件”，但它本身并不构成 TDD，至少根据经典定义，其中重要的一点是让测试通过才是驱动设计的动力（而不是一些正式的设计文档）。 2）同样，经典观点认为，重要的一点是设计是从测试中演变而来的，迫使它变得非常模块化。这是（或者曾经是）一个新颖的概念，即测试可以（并且应该）影响设计，并且可能经常被拒绝或忽视，以至于 TDD 支持者开始觉得需要强调它。但在我看来，说测试本身“只是副产品”是一种适得其反的夸张。

Answer 2

维基百科的文章

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

Answer 3

当您在测试之前有代码时，没有红色，这很糟糕，因为您可能在测试中出现错误或测试其他内容，然后您认为自己正在测试并从一开始就得到绿色。您应该是红色的，然后只有在添加经过该测试测试的代码后才转到绿色。

（来源：
at reddevnews.com_）

Answer 4

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

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

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

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

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