我在几年前发现了TDD，从那时起我就使用它编写了所有我喜欢的项目。我估计，TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同，但我对最终产品的信心增加了，以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面，以防我需要一起模拟东西)，而且，正如顶部的绿色帖子所写的，它有助于“编码便秘”:当你不知道接下来要写什么，或者你有一个令人生畏的任务摆在你面前时，你可以写小一点的。

最后，我发现到目前为止，TDD最有用的应用是在调试中，如果仅仅因为您已经开发了一个询问框架，那么您就可以用它来刺激项目以可重复的方式产生错误。

这是非常以. net为中心的，但是有人尝试过Pex吗?

我非常怀疑，直到我尝试了——哇，多么精彩的表演。以前我想“我不会被这个概念说服，直到我明白它实际上对我有什么好处”。我只跑了一次就改变了主意，说:“我不在乎你怎么知道那里有致命异常的风险，但现在我知道我必须处理它”

也许这种行为唯一的缺点是它会标记所有事情，给你六个月的积压。但是，如果你有代码债，你总是有代码债，只是你不知道而已。告诉项目经理可能有20万个故障点，而你之前只知道有几十个，这是一个令人讨厌的前景，这意味着首先解释这个概念是至关重要的。

作为一名物理专业的学生，我非常有动力去证明我的代码是可以正常工作的。您可以从逻辑上证明这一点，随着实现变得更加复杂，难度会急剧增加，或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明，就必须进行测试。唯一的选择是说“我认为代码可以工作....”

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力，有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是，您可以毫不费力地运行它们几次，并且在第二次或第三次运行之后，您所浪费的时间和精力已经得到了补偿。

最后一个建议是，不仅要对代码进行单元测试，还要先进行测试(详见TDD和BDD)。

多年来，我一直试图说服人们，他们需要为自己的代码编写单元测试。无论他们是先编写测试(如TDD)还是在编写功能之后，我总是试图向他们解释对代码进行单元测试的所有好处。几乎没有人反对我。你不能否认一些显而易见的事情，任何聪明的人都会看到单元测试和TDD的好处。

单元测试的问题在于它需要行为上的改变，而要改变人们的行为是非常困难的。用语言，你会让很多人同意你的观点，但你不会看到他们做事的方式有太多变化。

你必须通过行动来说服人们。你的个人成功会比你的争论吸引更多的人。如果他们看到你不只是在谈论单元测试或TDD，而是在做你鼓吹的事情，而且你是成功的，人们就会试图模仿你。

You should also take on a lead role because no one writes unit test right the first time, so you may need to coach them on how to do it, show them the way, and the tools available to them. Help them while they write their first tests, review the tests they write on their own, and show them the tricks, idioms and patterns you've learned through your own experiences. After a while, they will start seeing the benefits on their own, and they will change their behavior to incorporate unit tests or TDD into their toolbox.

改变不会在一夜之间发生，但只要有一点耐心，你就可能实现你的目标。

如果你正在使用NUnit，一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试，胜过千言万语……