Posted on 2011-09-15 06:37
RTY 阅读(342)
评论(0) 编辑 收藏 引用 所属分类:
转载随笔 、
质量保障
刚接触单元测试时，我实在是搞不懂这种测试到底有多大的意义，无非都是一些简单的ASSERT，但近年积累一些经验教训之后我才发现，单元测试这玩意儿真的是一种保证程序质量的强有力手段。
为什么这样说？举个最典型的例子，无论是开发新功能还是维护老程序，都不可避免的要反复修改某些代码，那该怎么保证修改的代码不会引入新的问题？如果你说你用人品担保，那我服了。我们应该需要一种可靠的手段来保证修改一个BUG不会引入两个三个BUG，或者不会让之前正确的功能出错，甚至是不会引入之前已经修改过的其它BUG。测试无疑是一种很好的手段，在没掌握其它更好的方法之前，很多人喜欢用人工测试，即编译 – 运行 – 输入典型值 – 看程序运行结果 – 如果出错 – 修改后再编译……从长远来看，这种测试方法的缺点很明显：1、耗时耗力，每次修改代码后都需要人工重复测试所有的典型情况；2、容易出错、漏测，人脑太复杂，你很难记得几个月前的那个BUG到底是什么情况，因此没法测试，久而久之，N久前的那个BUG可能又神不知鬼不觉的重现了。相比之下，单元测试的优点就凸显出来了，把需要测试的典型情况编写为测试代码，然后编译运行即可完成自动化的测试，当发现BUG后，把它添加到测试用例，不仅可以提高测试覆盖率，还能保证以后不会再次引入同样的BUG，有了足够的单元测试（覆盖率），你就可以理直气壮的说代码没问题！当然引入单元测试会在前期花费不少的时间来编写测试代码，但相应的也会大大减少后期的维护工作，最主要的是能可靠的提高程序的质量，所以是值得的，甚至是必要的。（如果你编译过开源的Google Chromium浏览器，你会发现测试代码就占了不少，光是编译测试代码就得花很长的时间）
除了上面说的优点外，单元测试还有一些其它的好处，比如帮你理清设计。一些人反对单元测试就是因为说我们的应用太复杂了，没法做单元测试。其实不一定是应用复杂，而有可能是设计得有问题，导致了没有可测试性。比如有些人喜欢在CXXXDialog里编写所有的功能实现，要测试这样的代码，必须得创建出Dialog，可能还需要点击，这显然没法做单元测试，但如果把Dialog和业务逻辑分开设计，那至少业务逻辑是可测试的（暂不讨论UI的测试）。因此要做单元测试，就得设计好各个接口，保证某个接口只完成单一的功能，没有过多的耦合依赖。
前面只是泛泛而谈了一些单元测试的皮毛，鼓吹了一些优点，有兴趣的自己找更详细的资料看吧。另推荐一个Google的开源C++测试框架googletest。