单元测试的实施(以VU为例)

 

　　单元测试由谁来做？单元测试由测试部门来做还是由开发部门来做，是一个引起广泛争论的话题。我们的观点是：由测试部门和开发部门共同来做：测试部门负责制定规范、培训，并检查测试效果；由开发部门负责具体的实施，最好是边开发边测试。

　　测试部门可能不具备实施单元测试的足够人手，即使测试部门有足够的人手，即使项目时间允许，完全由测试部门实施单元测试也会造成资源的较大浪费，因为测试人员要花很多时间来重新理解代码，同时，充分的单元测试通常会发现很多细小的错误，程序员修改代码时，又要再一次理解代码；另一方面，如果等编码基本完成再由测试部门进行单元测试，也就不能发挥单元测试对代码整体结构的约束效果，测试部门拿到代码时，往往会发现难于测试。当然，已经完成编码的项目也不是不能进行单元测试，只不过可能要花费一定的时间成本对代码进行整理重构，后文会有进一步的论述。

　　由开发人员实施单元测试，当然也有问题，主要有：一是程序员可能不喜欢做单元测试；二是开发部门可能担心影响开发进度；三是由于思维定势的原因，不容易保证测试的完整性。我们在设计VU的过程中，充分考虑了这三个问题，提供了切实可行的解决方法和工具。

　　很多开发人员不喜欢做单元测试，甚至抵制单元测试，对于这种现象，常见的说法是程序员太自信，觉得自己的代码不会有错，所以不愿意进行单元测试。这种说法就好象在说程序员“自以为是，不负责任”，所以不愿意做单元测试。事实是这样的吗？作为程序员，我们自己并无这种心理，也调查过一些程序员，没有谁真的有这种心理，实际上，哪个程序员没有翻江倒海地排查一个小小错误的经历？谁写的代码也不能保证毫无错误，人不是机器，即使编程时思维缜密到没有任何疏漏，也还可能有“笔误”呢。那么，程序员为什么不喜欢做单元测试呢？我们认为，主要还是程序员的工作特点造成的。编程是创造性的工作，编程的最大乐趣就在于看到了自己的劳动成果出现在眼前，这就使程序员常有一种“立即实现”的冲动；另一方面，程序员的思维往往是跳跃向前的，当程序员开始了编程思路之后，一般就不愿意中断思路，花较多时间去编写测试代码了；再一方面，跟测试工具也有一定关系，一般的单元测试工具只显示“通过”，“失败”两种状态，相对而言，在产品工程中直接观看代码的运行结果