我与我的同事就单元测试和测试驱动开发进行了辩论。主题如下：
1）在编写功能代码之前编写单元测试并不构成测试驱动开发方法
我认为编写单元测试确实构成了测试驱动开发，它是TDD的一部分。
2）一套单元测试只是TDD的副产品。
一套单元测试不是TDD的副产品。
你说什么？
答案 0 :(得分：9)
1）在编写功能代码之前编写测试必要来做TDD，但是它本身并不构成TDD，至少根据经典定义，其中重点是进行测试pass是驱动设计的原因（而不是一些正式的设计文档）。
2）同样，经典观点认为重要的一点是设计从测试演变而来，迫使它变得非常模块化。它是（或曾经）一种新颖的概念，测试可以（并且应该）影响设计，并且可能经常被拒绝或忽视，以便TDD支持者开始觉得需要强调。但是说测试本身“仅仅是一种副产品”是IMO的一种适得其反的夸张。
答案 1 :(得分：4)
在编写功能代码之前编写单元测试是TDD的重点。因此，单元测试套件不是副产品，而是核心内容。
测试驱动开发（TDD）是一个依赖于非常短的开发周期重复的软件开发过程：首先，开发人员编写一个失败的自动化测试用例，定义所需的改进或新功能，然后生成代码通过该测试并最终将新代码重构为可接受的标准
答案 2 :(得分：4)
TDD就是Red - Green - Refactor。
如果你在测试之前有代码，那么没有Red，这是不好的，因为你可能在测试中有错误或测试其他的东西然后你认为你正在测试并从一开始就获得Green。您应该是Red，然后在添加由该测试测试的代码后才转到Green。
答案 3 :(得分：2)
这实际上取决于你的测试。
就我而言，TDD意味着由于首先为它们编写测试而创建了代码类，属性和方法。事实上，一些开发工具允许您直接从测试屏幕创建代码存根。
为已经创建的类中的方法编写单元测试不是TDD。编写使测试用例通过的代码是。
TDD将为您提供比标准单元测试更大的测试覆盖率。它还会将您的想法集中在代码所需的内容上，虽然根据定义生产产品可能需要更长的时间，但在构建时或多或少都会进行全面测试。
最后，你总会得到一套单元测试。
然而，必须采取务实的方法来解决这个问题，因为在TDD环境中一些区域很难生产，例如：使用javascript的WPF MVVM样式视图或网页。