一般认为,单元测试有四种作用:
(1)使代码可以放心修改和重构;
(2)迫使程序员从调用者而不是实现者的角度设计软件模块;
(3)迫使程序员将软件模块写得易于测试和调用,从而有利于解耦;
(4)测试本身可作为被测代码的用法说明,从而替代了一部分文档功能。
如果更深入地考虑单元测试的作用,它还可以从“用户”和“需求”角度来阐释。
一般认为软件的用户就是使用软件的人,而用户需求通常表现为一纸文档。然而,这个人在哪里?他今天能来吗?这份文档是谁在维护?今天下午他能对着文档帮你看看实现吗?昨天有人改过这份文档吗?想想这些问题的答案,你都能感觉到事情有多么飘乎……在软件开发中,或者说至少在软件实现中,不够具体的东西作用总是有限的,有时甚至仅有“想象”中的作用。
而且,从更细的粒度来看,“软件模块”的用户跟“软件”的用户不是一个概念。对一个模块来说,它的直接“用户”是调用它的其它模块,而不是用户界面之外的人。从这个角度,写下单元测试的时候,不仅模块的需求得到了明确表达,模块还有了独立的、具体的、有效的第一个“用户”。说它是独立的,至少意味着远在其它模块完成之前你的模块就已经有“用户”了;说它是具体的,是因为它真正“使用”你的模块,而不只是扔给你一份文档看看;说它是有效的,是因为它随时可以运行,一运行就用遍模块的所有接口。
在企业中市场部门的员工看来,最喜人的事情莫过于产品开发之前就已经有了明确的需求和忠实的用户;“测试驱动开发”中强调的“代码未动,测试先行”与此有异曲同工之妙。