软件开发中的单元测试：价值、实践与工具
在软件开发领域，测试一直是一个备受关注的话题。曾经，我认为测试是质量保证（QA）人员的工作，与我作为开发者的职责无关。当像 Kent Beck、Ron Jeffries、Ward Cunningham 等人开始推广测试对开发者有价值且应成为开发过程一部分的理念时，我持怀疑态度。但当我真正开始编写测试后，很快就意识到了它的价值。
测试的经济性
在软件开发中，有些实践几乎没有成本，能随时遵循，让我们将精力集中在更复杂的问题上。然而，有些实践是有成本的，要使其成为日常工作的一部分，就必须为开发过程带来巨大价值，解决诸多问题并提供关键指导。单元测试就是这样一种高级实践。
这里存在一个有趣的矛盾现象：
- 大多数软件开发专业人员都称赞测试的优点，且大多数现代软件开发流程都将测试列为项目的必要元素之一。
- 但很多（甚至可以说大多数）软件开发人员除了确保代码能编译和进行简单的手动功能测试外，不会对代码进行更多测试。
造成这种现象的主要原因是，大多数人觉得测试成本太高。开发者常说“我太忙了，没时间写测试”“如果写测试，我就没时间写代码了”。许多项目经理也因担心开发者陷入测试而降低效率，不鼓励正式测试。另外，团队常被要求最后编写测试，开发者认为对着已经能运行的代码写测试毫无意义。而且，给没有考虑测试性而编写的代码添加测试通常是一件痛苦且烦人的事，因为能运行的代码不一定具有良好的测试性，测试往往粒度太粗，不太有用。
那么测试到底值不值得呢？根据我的经验，答案是肯定的。在设计演变过程中，我非常依赖低层次的测试（即单元测试），并且通过易于使用的工具实现自动化。
