.net中的测试驱动开发和单元测试

TDD测试通常(但不总是)是单元测试。非单元测试的例子可能是使用WaitiN的UI测试。考虑TDD的最简单方法是将其视为确保尽可能多的需求(包括业务和技术需求)以编程方式表达的规程，以便您可以一致且有规律地将它们应用于代码库，以确保在进行更改时仍然满足需求。

在实践中，这倾向于在您的体系结构中产生不同的(有些人认为更好的)模式，通常趋向于解耦，以允许模块单独进行测试。在更严格的TDD环境中，首先开发您的测试(这样它就会失败)，然后开发您的代码来满足您的测试是很常见的。这个规程确保您的测试完全表达了您的需求的意图。

TDD测试绝对可以是单元测试。

它们当然属于"单元测试"的定义，根据维基百科:http://en.wikipedia.org/wiki/Unit_testing

表面上看，TDD测试与单元测试非常相似。这并不奇怪，因为您使用了单元测试框架(如Visual Studio Tests或NUnit)来创建这两种类型的测试。但是TDD测试和单元测试是有区别的。

像单元测试一样，TDD测试可以用于回归测试。您可以使用TDD测试立即确定代码中的更改是否破坏了现有应用程序的功能。然而，与单元测试不同的是，TDD测试并不需要单独测试一个代码单元。

与验收测试一样，TDD测试用于驱动应用程序的创建。TDD测试类似于小型验收测试。您创建一个TDD测试来表达接下来需要实现的应用程序功能。然而，与验收测试不同，TDD测试不是端到端测试。TDD测试不与实时数据库或web服务器交互。

Roy Osherove (Art of Unit Testing的作者)对此有一个不错的视频:

理解测试驱动开发

主要的区别在于您是在前面创建测试(指示您希望代码做什么)而不是在之后创建测试(测试您已经编写的代码)。因此，理论上，您的TDD测试应该已经涵盖了您编写的产品代码。纯TDD建议您不应该编写一行新的产品代码，除非您有一个失败的测试需要它。有了经验，你可以决定你要多严格遵守这个原则。