大多数开发者都讨厌测试，他们往往会温和地测试，下意识的知道代码会在哪里出问题，并避开那些薄弱地方。注重实效的程序员与此不同。我们受到驱使，现在要找到我们的bug，以免以后经受由别人找到我们的bug所带来的羞耻。
　　寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）捕捉吃人的鲨鱼。有时鱼会设法逃跑，所以为了抓住在我们的项目池塘里游动的，越来越狡猾的缺陷，我们要补上我们发现的任何漏洞。
　　提示
　　Test Early，Test Often，Test Automatically。早测试，常测试，自动测试。
　　一旦我们有了代码，我们想开始进行测试。那些小鱼苗有飞快地变成吃人的大鲨鱼的可恶习惯，而抓住鲨鱼会困难许多。但我们又不想手工进行所有这些测试。
　　许多团队都会为他们的项目精心制定测试计划。有时他们甚至会使用这些计划。但我们发现，使用自动测试的团队成功地机会要大很多。与呆在架子上的测试计划相比，随每次构建运行的测试要有效很多。
　　bug被发现得越早，进行修补的成本越低。“编一点，测一点”是SmallTalk世界里流行的一句话，我们可以把这句话当做我们自己的曼特罗，在编写产品代码的同时（甚至更早）编写测试代码。
　　事实上，好的项目拥有的测试代码可能比产品代码还要多。编写这些测试代码所花的时间是值得的。长远来看，它后会便宜的多，而你实际上有希望制作出接近零缺陷的产品。
　　此外，知道你通过了测试将给你高度的自信，一段代码已经“完成”了。
　　提示
　　Coding Ain't Donw Til All the Tests Run 要到通过全部测试，编码才算完成。
　　你写出了一段代码，并不意味着你可以告诉你的老板或客户，说它已经完成。不是这样。首先，代码从不会真正完成，更重要的是，在它通过所有可用的测试之前，你不能声称它已经可供使用。
　　我们需要查看项目范围测试的三个主要方面：测试什么，怎样测试，以及何时测试。
　　测试什么
　　你需要进行的测试的主要类型有：
　　●单元测试
　　●集成测试
　　●验证和校验（validation and verification）
　　●资源耗尽、错误和恢复
　　●性能测试
　　●可用性测试
　　这份列表绝不是完整的，有些特殊的项目还需要各种其他类型的测试，但它给了我们一个很好的出发点。
　　单元测试
　　单元测试是对某个模块进行演练的代码。单元测试是所有其他形式的测试的基础。如果各组成部分自身不能工作，它们结合在一起多半也不能工作，你使用的所有模块都必须通过它们自己的单元测试，然后你才能继续前进。
　　集成测试
　　集成测试说明组成项目的主要子系统能工作，并且能很好地协同，如果在适当的地方有好的合约，并且进行了良好的测试，我们可以轻松地检测到任何集成问题。否则，集成会变成肥沃的bug繁殖地。事实上，它常常是系统的bug来源中大的一个。
　　集成测试实际上只是我们描述过的单元测试的一种扩展——只不过现在你的测试的是整个子系统遵守其合约的情况。