我是TDD的新手，想知道从哪里开始。我已经尽可能多地阅读了自己的想法，但仍然不知道要测试什么和测试什么。例如，我知道，从阅读中，我们不应该对数据库运行测试，从而进入模拟框架。我们嘲笑我们的存储库，以便他们返回假数据。我的问题是我们测试数据常量的需求吗？例如，要求可能的状态，一个人应该始终有一个名字，即：TDD和测试数据
Assert.IsNotNull(personObject.Name);
应始终是真实的，但我怎么测试它不具有“假”的数据？我是否在意测试这种类型的需求？
让我们按照你的要求“一个人应该永远有一个名字”。我们可以从哪里开始？
首先，我们需要一些清晰。我相信当你说“应该永远有一个名字”时，你的意思是“永远不应该有一个空或空字符串”作为名称。
我们可能真正意义的是“当一个人存储在我们的数据库中时，它的名字不能为空或空的。第一道攻击将是在数据库中加以约束，然而，没有任何东西可以防止流氓数据库管理员移除该限制，因此您可能需要测试一下您对系统的真实情况，如果它发生更改，则会由失败的测试标记。为此，您可以编写一个测试，例如“当我的应用程序发送一个空名称的人员保存到数据库时，它应该失败”。这不是一个单元测试，它更像是一个集成测试 - 编写起来比单元测试更复杂。
但是，这仍然不包括流氓DBA删除约束并直接创建具有空名称的记录的情况。换句话说，您的应用程序无法相信所返回的数据是正确的，因此问题就变成了：您希望您的域如何处理具有空名称的人的可能性？
一个非常直接的方法可能是强制该Person只能使用非null名称构造，否则抛出。这将很容易进行单元测试和执行，但可能会使开发变得痛苦。更令人愉快的方法是对Person没有约束，而是一个Validator类，它可以验证一个人是否有违规规则。这是更可口的，因为你现在可以做任何你想要的人（比喻），然后验证该人是否仍然处于有效状态。
这有
1）是很容易测试的好处：创造这样一个验证单元测试是小菜一碟，
2）解决流氓DBA问题：你现在可以验证所有来自或去到应用程序外部的应用程序，通过应用验证器。
所以，作为懒惰的开发就是我，这就是我将开始：去的验证，因为它解决了我的问题，而被更容易比涉及的一些数据进行测试。换句话说，总的来说，我倾向于尽可能多地使用单元测试（即完全在内存中），并且尽可能地在代码/域中尽可能多地使用我的业务逻辑，因为它更容易集成在一起放置，并且更容易测试。
您可以使用验收或集成测试来覆盖您的数据库和约束条件。例如，在一个项目中，我们有一个单独的“集成”包，其中包含检查NHibernate绑定的测试。如果你不使用NHibernate，你可以在你的仓库中做到这一点，保持数据库连接。您可以从此级别验证约束，参照完整性等。
如果你还在寻找关于TDD的其他方面的指导，尝试Dan North's post on BDD，开始：
“我有一个问题...程序员想知道从哪里开始，测试什么，什么不可以测试，一次测试多少次，测试什么，以及如何理解测试失败的原因。“
你应该*测试数据库，而不是在你的单元测试中。 – coreyward 2011-01-23 01:23:32