单元测试（一）－－浅谈

    单元测试（(unit testing),）：它是项目成功、个人成功的一个不可或缺的部分，但对它，人们却又存在各种各样的误解。单元测试其实是相对廉价而简单的技术，但它能让你更高效地写出质量更好的代码。

    说到测试，大凡组织和个人都会满怀雄心壮志，但是往往只是在项目快要结束的时候才想起测试。而那时的进度压力一定非常紧迫，所以结果往往只是浅尝辄止或者干脆就不测试了，这样就起不到预防缺陷的意义了。

    许多程序员觉得测试只是一件麻烦事：一种自找的烦恼，唯一的“效果”就是让他们没法专注于手上的正经事－－cutting code（堆砌代码）。

    如何给程序员减压，但又能做好单元测试呢? 中小企业的程序员和项目经理，一般面对的都是压力大、任务重的项目。 如果作为项目经理的你，觉得测试组有人(有人就行了,多少倒不大重要)，不妨让测试组的人早点介入单元测试，又或者假如测试组的人起码能写点代码，那其实更好，那么分配测试组的人去写单元测试，这其实是很有好处的。

     每个人都同意，该做更多的测试。这种人人同意的事情还多着呢，该多吃蔬菜，该戒烟，该多休息，该多锻炼......这并不意味着我们中的所有人都会这么去做，不是吗？

    但是单元测试却远远不仅仅是上面这些－－也许你会认为单元测试是花菜那一类的，而我要说它更像一勺美味的调料，它让每份菜肴品尝起来都更加可口。单元测试的设计目的并不是为了获得一些更好的整体质量。也就是说，它并不是一个针对最终用户、项目经理或开发组长的工具；而是由程序员自己来完成，并且最终受益的也是程序员自己。我们为了自身的利益去使用单元测试的，从而让我们的工作变得更加轻松，甚至大大减少你花在调试上面的时间。

    当基本的底层代码不再可靠时，那么必需的改动就无法只局限在底层，虽然你可以修正底层的问题，但是这对底层代码的修改必然会影响到高层代码，于是高层代码也连带地需要修改；以此递推，就很可能会动到更高层的代码。于是，一个对底层代码的修正，可能会导致对几乎所有代码的一连串改动，从而使修改越来越多，也越来越复杂。项目中存在的风险越来越高，导致整个项目的失败的可能性也越来越大。

    简而言之，在有些时候，使用单元测试本身就能决定你的项目的成败。