这可能是一个愚蠢的问题，但我的谷歌搜索没有找到令人满意的答案。我正在用 C# 开始一个小项目，只有一个业务层和一个数据访问层 - 奇怪的是，UI 稍后会出现，而且我对它的外观几乎没有（阅读：没有）概念/控制。
我想为这个项目尝试 TDD。我正在使用 Visual Studio 2008（即将是 2010 年），我有 ReSharper 5 和 nUnit。
再次，我想做测试驱动开发，但不一定要做整个 XP 系统。我的问题是 - 我何时何地编写第一个单元测试？
我是只在编写逻辑之前测试逻辑，还是测试所有内容？测试没有理由失败的东西（自动属性、空构造函数）似乎适得其反……但似乎“没有失败的测试就没有新代码”的格言要求这样做。
链接或参考都很好（但最好是在线资源，而不是书籍 - 我想尽快开始）。
提前感谢您的指导！
【问题讨论】：
标签： unit-testing tdd nunit
测试似乎适得其反 没有理由失败的事情 （自动属性，空 构造函数）...
它是...在空的构造函数或自动属性中没有要测试的逻辑。
我什么时候写第一个 单元测试？
在编写第一行可测试代码之前。想想你希望你的方法执行的行为。根据所需的行为编写测试。该测试（以及随后的所有其他测试）体现了您的程序规范。
我在哪里编写第一个单元测试？
在您创建的第一个测试类中。
这可能是最好的在线资源：
测试驱动设计 (TDD) 简介
http://www.agiledata.org/essays/tdd.html
【讨论】：
您必须深入了解 TDD 的思维方式转变。如果你不做 TDD，你通常会写一些代码，然后写一个单元测试来确保代码符合你的期望，并处理一些不同的极端情况。使用 TDD，您实际上首先编写了一个测试，该测试通常使用您尚未编写的类和方法。
一旦您编写了测试，并且您对测试是应该如何使用您的代码的一个很好的示例感到满意，您就开始编写实际的类和方法以使测试通过。
一开始有点难，因为你没有智能感知的帮助，而且你的代码在你真正实现生产代码之前是不会构建的，但是通过首先编写测试，你不得不考虑你的代码是如何会在你写之前使用。
【讨论】：
测试似乎适得其反 没有理由失败的事情 （自动属性，空 构造函数）...
这似乎适得其反，但如果您的代码依赖于新构造对象的默认状态，那么值得进行测试。有人可以进来并更改字段的默认值，您的代码就会中断。
请记住，您的测试不仅是为了发现失败的东西，而且是为了验证您的代码是否符合其宣传的合同。你可以争辩说你不需要担心——如果合同失效，那么依赖于它的代码也会失效。这是真的，但会创建因“远程”问题而失败的测试。理想情况下，一个类的问题应该首先导致它自己的单元测试失败，而不是它的客户端的单元测试。
在没有任何要求或设计的情况下进行 TDD 是很困难的。在传统的编码中，你坐下来敲出你想要的东西，需求随着代码的发展而变化——需求几乎来自代码，因为你更深入地挖掘并更详细地发现你需要什么。但是对于 TDD，测试是需求的体现，因此您必须预先准备好这些，并且在您的脑海中一清二楚。如果您是从一张空白纸开始，那么您必须同时进行需求分析、测试设计和代码设计。
【讨论】：
引导 TDD 的一种方法是先编写集成测试——也就是说，在任何单元测试之前。此集成测试旨在证明您的应用程序在端到端意义上按预期工作。
显然，应用程序尚未编写，因此您的初始集成测试不会检查很多东西。例如，假设您正在编写一个数据处理程序，该程序应该分析一个平面文件并生成一份摘要报告。一个简单的端到端测试将调用该程序，然后确认在预期位置生成了一个文件。该测试将失败，因为您的应用尚未执行任何操作。
然后您编写应用的最小版本以满足简单的集成测试。例如，应用程序将运行并将摘要报告的硬编码标题写入文件。在当前的形式中，您的应用程序有时被称为行走的骨架——在某种程度上是现实功能的最薄的部分。
从那时起，您将肉添加到骨架中——当然，在编写每个新功能之前编写一个测试。一旦你开始这样做，“首先测试什么”的问题就会变得更容易处理，并且你的许多新测试将是面向单元的（而不是面向集成的）。
【讨论】：