尽管关于测试驱动开发(TDD)的书和文章有成百上千之多，仍然有很多人从未感受过测试的强大力量。

之所以不愿意去写测试程序不外乎有以下几个理由：

1. 太费时间。

2. 不值得。

3. 我很懒。

4. 我不知道如何做。

5. 我知道我的程序好用，我运行过一次，没出问题。

6. 我是超人，我从来不犯错误。

除非你的答案是6.(如果是这样，我很羡慕你)，否则，你应该继续读下去。

让我们从一个简单的例子开始。就说你要写一个Email地址校验程序。

你也许会使用正则表达式，或手工实现每个字符的对比，来完成这个任务。

现在你想验证一下你的代码是否有效。你会怎么做？你可以手工输入不同的值来验证它是否符合你的要求，结果你就测试了像下面的这些东西：

foo
foo@bar
foo@bar.baz
...

如果你要改变/调整校验算法会发生什么？你需要把之前所有的过程全部重复一遍，把每个值都再输入一遍，看看校验的结果。如果让计算机自动的帮你校验这些是不是会更好些呢？

通过把测试过程自动化，你可以在任何时候对程序进行任何遍次的测试。这不仅仅在以后会节省你大量的时间，而且会增加你的自信心，因为每次当你感觉到程序可能出错时，只要运行一下你的测试程序，看看测试结果就行了。

现在设想一下你正在编写一个更加复杂的程序，比如XML解析器。

你不可能编写出解析器后不去测试它，问题是，你如何测试它？通常，你会创建一个XML样板文件，把它输入解析器里，手工检查解析的结果。当你看到解析器按照要求输出了你期望的结果后，你确信你完成了任务，解析器没问题。

问题就在于如果你发现了一个Bug。那你就需要去修改你的代码，再验证一次它是否好用。可是我们程序员都是一群懒人，我们会只测试我们遇到的这个Bug，几乎从来不会去测试解析器的其它部分。这会产生什么问题呢？你能确保没有把什么东西改坏？

当你写了单元测试程序后，这个工作流程会变的怎样？

首先，你已经对程序进行过测试，之前你必须对每个函数进行手工的测试，手工的检查输出结果。如果这种事情你只需要做一次，那也没什么了，但当有东西出错时，你不想一遍一遍的重复做这个事情，没有人喜欢来回重复的做相同的事情，特别是无聊的事情。

另一种情况，你为你的解析器里的每个功能都写了自动测试程序。在这个例子中，你已经测试过你的程序，对这个过程你并不陌生。你需要做的是把手工的检查改为assertions，它们会为你自动测试程序。

当Bug出现时，巨大的变化发生了。

如果没有自动化测试，你必须手工的检查所有的东西来确保你在修正一个Bug时不会引入其它的错误。当有数个Bug出现时，你会变得极不耐烦，你开始 不再检查其它部分的代码，只关注你的这个Bug。但假如你为程序写好了自动化测试，你唯一要做的就是点击一次按钮，让所有的测试程序运行起来，你马上就能 看到测试结果，几乎不需要在其它任何事情。

当有了测试程序后，修改Bug是怎样进行的？

首先，你需要重现这个Bug。无论如何，在你修改前，你必须要认定这个Bug是否真实的存在。如何做到这些？你要写出一个测试用例来重现这个bug，这个必须要在你做任何的修改这个bug的工作之前完成。

如果这个bug不能重现，问题就可能出自其它地方，如果不能用自动化测试来重现这个bug，你可能在错误的地方修改了这个bug，很可能改坏了你的程序。当你写出测试程序，你必须先运行它确保它会失败。如果测试没有失败，什么地方可能出了问题，你没能正确的重现它。

当你修改了这个Bug，你也有了针对它的测试程序，你可以立即发现这个bug是否还会出现。

当你这时又发现另外一个bug时该怎么做？

相同的做法。写一个测试程序，重现这个bug。即使你没有时间来立即修正这个bug或者这不是个致命的bug，你也应该有个能够让它重现的测试程序，当日后你回来解决这个问题时，你就能知道该做什么了。

来源：51CTO