单元测试和TDD通常能让你对所编写的软件有更短的反馈周期。与在实现的最后有一个大型测试阶段不同，您可以增量地测试您所编写的所有内容。这大大提高了代码质量，正如您立即看到的那样，您可能会有错误。

我在FoxForward 2007参加了一个关于单元测试的演讲，被告知永远不要对任何与数据相关的东西进行单元测试。毕竟，如果您在实时数据上进行测试，结果是不可预测的，如果您不在实时数据上进行测试，那么实际上并不是在测试您所编写的代码。不幸的是，这是我最近编写的大部分代码。: -)

最近，当我编写一个保存和恢复设置的例程时，我确实尝试了TDD。首先，我验证了是否可以创建存储对象。然后，它有我需要调用的方法。然后，我可以称之为。然后，我可以给它传递参数。然后，我可以给它传递特定的参数。依此类推，直到我最终验证它将保存指定的设置，允许我更改它，然后为几种不同的语法恢复它。

我没看完，因为我现在需要例行公事，但这是一个很好的练习。

如果给你一堆垃圾，你似乎陷入了一种永久的清理状态，你知道任何新功能或代码的添加都会破坏当前的设置，因为当前的软件就像一个纸牌屋，你会怎么做? 那么我们如何进行单元测试呢?

从小事开始。我刚加入的项目直到几个月前才开始进行单元测试。当覆盖率如此之低时，我们将简单地选择一个没有覆盖率的文件并单击“添加测试”。

现在我们已经达到了40%以上，我们已经成功地摘走了大部分容易摘到的果实。

(最好的部分是，即使在这样低的覆盖率水平上，我们已经遇到了许多代码做错误事情的实例，并且测试发现了它。这是促使人们增加更多测试的巨大动力。)

测试驱动开发在某种程度上取代了单元测试这个术语。作为一个老手，我会提到它的更一般的定义。

单元测试还意味着测试一个较大系统中的单个组件。这个组件可以是dll、exe、类库等。它甚至可以是多系统应用程序中的单个系统。因此，单元测试最终是对一个更大系统的单个部分进行测试。

然后，您可以通过测试所有组件如何一起工作来进行集成测试或系统测试。

单元测试与“只是打开一个新项目并测试这个特定的代码”的主要区别在于它是自动化的，因此是可重复的。

如果您手动测试代码，它可能会使您相信代码在当前状态下工作得很完美。但一周后，当你对它做了轻微的修改时呢?您是否愿意在代码发生任何更改时再次手工重新测试?很可能不会:-(

但是，如果您可以在任何时间运行您的测试，只需单击一下，以完全相同的方式，在几秒钟内，那么一旦有什么东西坏了，它们就会立即显示给您。如果您还将单元测试集成到您的自动化构建过程中，即使在看似完全无关的更改破坏了代码库中遥远部分的某些情况下，它们也会提醒您错误——当您甚至不会想到需要重新测试特定的功能时。

这是单元测试相对于手工测试的主要优势。但等等，还有更多:

unit tests shorten the development feedback loop dramatically: with a separate testing department it may take weeks for you to know that there is a bug in your code, by which time you have already forgotten much of the context, thus it may take you hours to find and fix the bug; OTOH with unit tests, the feedback cycle is measured in seconds, and the bug fix process is typically along the lines of an "oh sh*t, I forgot to check for that condition here" :-) unit tests effectively document (your understanding of) the behaviour of your code unit testing forces you to reevaluate your design choices, which results in simpler, cleaner design

反过来，单元测试框架使您更容易编写和运行测试。

I think the point that you don't understand is that unit testing frameworks like NUnit (and the like) will help you in automating small to medium-sized tests. Usually you can run the tests in a GUI (that's the case with NUnit, for instance) by simply clicking a button and then - hopefully - see the progress bar stay green. If it turns red, the framework shows you which test failed and what exactly went wrong. In a normal unit test, you often use assertions, e.g. Assert.AreEqual(expectedValue, actualValue, "some description") - so if the two values are unequal you will see an error saying "some description: expected <expectedValue> but was <actualValue>".

总之，单元测试将使测试更快，对开发人员来说更舒服。您可以在提交新代码之前运行所有的单元测试，这样就不会中断同一项目中其他开发人员的构建过程。