免费午餐——先写单元测试

  前些天看见有朋友的MSN签名档写着“unit testing”，就问了一下他们的单元测试是怎么做的。看来他们没有真正做起来，只是小范围的试一试。
        一方面，他们没有cruise control之类的工具，甚至连daily build都不见得有，单元测试也不上传到版本控制里。这样做测试的意义就不大了。
        另一方面，他好像把单元测试和接收测试（acceptance testing)、集成测试（integration testing）搞混淆了。因为他说，业务逻辑很复杂，测试数据不好做……

        单元测试，顾名思义，就是对一个单元的测试（好像什么也没说）。通常这个单元是指（类的成员）函数，或者函数的一个功能。
        每个测试就只针对一点，不涉及其余，还是比较好写的。函数的输入是什么，（对象当时的状态是什么），得到的输出是什么；有几种不同的情况……
        我感觉，同一个函数的单元测试加在一起，就相当于这个函数的详细设计文档。自然，设计文档应该在实现之前写，而不是实现了以后再补。
        和传统开发方法里的详细设计不同，写一个单元测试，就写一段代码让它通过。这样你就不需要在实现的时候，再去读文档，再去回忆当时是怎么想的，能提高效率；更重要的是，这个“文档”是能反复运行的，可以保证和实现的一致性。

        如果你的开发环境配置的好，照我的经验，写单元测试再写代码，和直接写代码相比，不会多花什么时间。
        编码过程中有相当一部分时间是花在想清楚下一步要做什么上，想到了就把它写成一个测试。这么做是要花一点点时间，不过能帮你尽快验证下面的实现跟你现在想的一致；能帮你理清思路，到底有几种情况需要考虑，就写几个测试；能让函数的功能更明确，只有功能明确，才能明确的测试；能让你的接口更合理，因为不合理的话，依赖关系太多或者接口太复杂，测试写起来会很麻烦……
        最重要的是，以后你改了什么东西，破坏了现在的接口，可以马上知道。不会在发版本的最后一天，才有人告诉你：“这个功能以前是好的，我们已经好几天没有重新测试了。现在坏了，不知道问题在哪里。全体加班吧！”
        不花什么时间，还有不少好处。免费午餐，为什么不试试呢？