单元测试难于长期坚持的原因与解决探讨

单元测试难于长期坚持的原因与解决探讨

这十年分为两个阶段，后六年专门研究单元测试技术与工具，前四年做一些外包项目。如果说因为单元测试已经成为我的专业，所以自己当然要做，那么，这也不能解释前四年之所以能坚持的原因。正是因为前四年的单元测试经历，才使我后来专注于单元测试领域。

回首十年的单元测试历程，我发现从来就没有刻意去坚持。我不是一个理性而有毅力的人，比较喜欢率性而为，能够十年不间断去做同一件事情，应该是因为，这其中有什么东西吸引了我，让我自然而然地想做而不是强迫自己去做。

一件事情，如果需要理性的力量，去勉强坚持，时间长了，热情会减退，惰性渐占上风，慢慢的可能就放弃了，例如健康的饮食习惯。有些事情，虽然从理性方面看未必好，但却容易使人沉溺其中不能自拔，例如玩网络游戏。为什么会这样呢?后者具有眼前的和感性的吸引力，形成了“诱惑”，自然让人喜欢做，长期做。眼前的感性的吸引力，往往能轻易打败后期的和理性的好处。

我想，正是因为单元测试的某些“眼前的和感性的吸引力”，形成了“诱惑”，使我乐于去做，而不是勉强去做。那么，是什么产生了“诱惑”呢?为什么单元测试没有形成普遍的“诱惑”呢?我做的单元测试和一般的单元测试有什么不同吗?

回想起来，不同确实是有的，从一开始，我使用的工具都是自己参与开发的。当时由于找不到满意的工具，所以自行开发，功能都是自己最需要的。

这个工具的第一个版本，主要功能是生成测试代码，修改一下就形成用例了。

第二个版本增加了自动生成用例的功能，使用之后很失望，因为工具不可能自动了解代码功能，自动生成的用例几乎没有什么用，在生成的一堆用例中去选择和修改，还不如直接写用例呢。

第三个版本增加了描述程序行为的功能，就是将被测程序在某些输入下，执行了哪些代码，产生了什么输出显示出来，也就是程序行为是可视的。这个功能太好用了，写几行代码就可以看看程序做了什么，编程的效率提高了，而工作强度却降低了，后来，我们把这种开发模式称为“可视编程”，“可视”，是指程序行为可视。

我所用的工具和一般测试工具最大就不同就在于支持可视编程，我所做的单元测试，与一般的单元测试最大的不同也在于可视编程。一般的单元测试，关注的是测试是否通过，而我写几行代码，执行测试后，首先看的是产生了哪些输出数据，除了一般的参数、成员变量、全局变量外，还包括中间结果，中间结果就是重要的变量或表达式在函数内部某个指定位置的值。如果输出数据跟我预想的不一样，再看看执行了哪些代码，这样就很容易找出错误，改正后再继续写。等代码写完了，最后再看看哪些测试没有通过，并对比输入输出与对应的已执行代码，找出错误原因，很少用调试，我使用调试器的能力已经严重退化了。

现在想来，“诱惑”我乐于长期做单元测试的“眼前的和感性的吸引力”就在于可视编程。比如说正在写一个比较复杂的函数，如果程序行为不可视，那么，我就要时刻想象已经写的代码会做什么，思路对不对也心里没底，当然难多了也累多了，而且调试最烦人，记得还没有做单元测试的时候，有时为了找一个小bug，三更半夜还在翻江倒海，好像什么都没错，就是结果不对，恨不得把电脑砸了。如果一边写代码，可以一边察看程序做了什么，感觉相当的爽，这就是“眼前的和感性的吸引力”。至于单元测试的其他好处，比较理性化，我一般不会想着这些好处的，反正只要做了单元测试，这些好处就跑不了。

可视编程强调是开发，而不是测试，不需要改变编程习惯，也不会造成思维被干扰，程序员是很怕被干扰的。如果工具比较自动化，可以生成测试代码什么的，那么可视编程也不需要什么额外的工作，我们在写代码时，一定需要想清楚代码的功能点，功能点一般就是会有哪些输入，各自会产生什么输出，列出来就是测试用例了，这不用花多少时间，而且还可以让自己对程序要实现的功能有更清晰的理解。

只要做了单元测试，那么，程序在什么输入下会执行哪些代码产生什么输出，这些数据就一定会存在，问题是有没有把它们利用起来。我觉得，多数单元测试理论和工具都忽略了这个宝贵的资源，是很可惜的。

至于可视编程能不能普遍解决单元测试难于坚持的问题，我不能下结论，欢迎讨论。我准备了一个视频，演示可视编程的过程，可惜上传到CSDN的资源库后被删除了，不知道什么原因。有兴趣看这个视频以及体验可视编程的朋友给我发CSDN短信。

如果感觉可视编程确实不错，也有望解决难于坚持的问题，那问题就有望解决，因为，不管您用的是什么工具，只要做了单元测试，那么，能够让程序行为可视的数据是一定存在的，想办法把它们捕获就是了。捕获的一般方式是插装，就是在被测代码中插入一些代码，用来输出数据以及监视代码的执行状况。

当然，要让单元测试真正顺利，还要消除会使测试“卡住”的主要阻碍，解决可测性问题，还要有好的测试效果，以及尽可能高效率