好的，我知道已经有关于如何开始使用TDD的问题了。然而，我想我知道一般的共识是要就这么做，但是我似乎遇到了以下问题：
那么，基本上我在这里寻找的不是“就这么做”，而是更多的“我曾经经历了这些问题，并通过这种方式解决了它们”..个人经验：）
首先，当你开始尝试在编程风格中使用TDD时，感到沮丧是很正常的。只要不要灰心丧气并放弃，你需要给它一些时间。这是对我们如何思考解决代码问题的一个重大范式转换。我喜欢将其看作是从过程式编程切换到面向对象编程的转变。
其次，我认为测试驱动开发首先是一种设计活动，用于通过创建描述它将公开的API以及如何使用其功能的测试来详细说明组件的设计。测试将帮助塑造和模型化被测试系统，直到您能够封装足够的功能以满足您正在处理的任何任务。
考虑到以上段落，请看看你的问题：
在问题一的答案中，我向您介绍了模拟术语。当您引入模拟技术到您的TDD武器库中时，它会大大地使得测试更容易抽象出不属于被测系统的部分。以下是一些可用的模拟框架资源:
除了阅读关于TDD的过程之外，帮助运用TDD的一种方式是观看其他人实践。我推荐观看JP Boodhoo在DNRTV上的屏幕录像。看看这些:
好的，这些将帮助你了解我介绍的术语是如何使用的。它还将介绍另一个名为Resharper的工具以及它如何促进TDD过程。在做TDD时，我不建议使用这个工具。看起来你正在学习这个过程，并且只是发现一些已经用其他工具解决的问题。
如果我没有通过添加Kent Beck在Pragmatic Programmer上关于测试驱动开发的新系列来更新这个内容，我想我会对社区犯下不公平的行为。
根据我的经验：
只测试自己的代码，不需要测试底层框架的代码。所以如果你使用了一个通用列表，就没有必要测试Add、Remove等操作。
没有第二点。看那边！猴子！！！
NUnit是最佳选择。
你肯定不能测试每一种情况的结果。我测试我期望发生的事情，然后测试一些边缘情况，其中我期望得到异常或无效响应。如果由于你忘记测试某些内容而导致了错误，那么在尝试修复错误之前，你应该首先编写一个测试来证明该错误存在。
我的观点如下：
作为补充，我想说一下，我已经发布了一篇博客文章，介绍了我的测试入门思路（根据这个讨论和我的研究），因为它可能对查看此线程的人有用。
"TDD – 入门指南" - 到目前为止，我已经得到了一些很好的反馈，并且非常感谢你们提供的任何意见。
希望这可以帮助！ :)
我并不是TDD的专家，但这是我的看法：
xUnit测试框架通常是免费使用的，因此如果您是.Net开发人员，请查看NUnit，如果您是Java开发人员，请查看JUnit。
