第六章:当你编码时(2)


四、易于测试的代码

我们需要在一开始就把可测试性构建进软件中,并且把各个部分连接在一起之前对每个部分进行彻底的测试。

单元测试

在隔离状态下对每个模块进行测试,目的是检验其行为。 单元测试是对模块进行演练的代码,在典型情况下,单元测试将建立某种人工环境,然后调用被测试模块中的例程。然后,它根据已知的值,或是同一测试先前返回的结果对返回的结果进行检查。 随后我们把模块装进完整的系统中,使用同样的单元测试设施把系统当做整体进行测试。 但是在此之前,我们需要决定在单元测试中测试什么。

针对合约进行测试

我们喜欢把单元测试视为针对合约的测试(参见按合约设计)。我们想要编写测试用例,确保给定的但愿遵守其合约。这将告诉我们两件事情:代码是否符合合约,以及合约的含义是否与我们认为的一样。我们想要通过广泛的测试用例与边界条件,测试模块是否实现了它允诺的功能。 如果测试模块依赖于其他模块,该如何对组合进行测试呢?首先测试模块的子组件,一旦子模块得到了检验,就可以测试模块自身。比如我们有一个使用LinkedList和Sort的模块A,那么按照顺序,我们会先全面测试LinkedList的合约和Sort的合约,然后测试A的合约。 我们为什么要这么“费事”?最重要的是我们不想制造“定时炸弹”——呆在周围不被人注意,却在项目后期的尴尬时刻爆炸的东西。通过强调针对合约进行测试,我们可以设法尽可能避免那些“下游的灾难”。
为测试而设计
当你设计模块、或者是单个例程时,应该既设计其合约,也设计测试该合约的代码。通过设计能够通过测试、并履行其合约的代码,你可以仔细考虑边界条件和其他非如此便不会发现的问题。没有什么修正错误的方法比从一开始就避免发生错误更好。

编写单元测试

模块的单元测试不应该仍在源码树的某个遥远的角落里,它必须放置在方便的地方,要记住,如果你不容易找到它,也就不会使用它。 通过测试代码易于被找到,你是在给使用你代码的开发者提供了两样无价的资源:
  • 一些例子,说明怎样使用你的模块的所有功能;
  • 用以构建回归测试、以验证未来对代码的任何改动是否正确的一种手段。
但只提供单元测试还不够,还必须运行它们,并且经常运行它们。

使用测试装备

因为我们通常都会编写大量的测试代码,并进行大量的测试,我们要让自己的生活更容易一些,为项目开发标准的测试装备。 测试装备可以处理一些常用操作,比如记录状态、分析输出是否符合预期的结果、以及选择和运行测试。 在面向对象的语言和环境中,可以创建一个提供这些常用操作的基类。各个测试对它进行继承,并增加专用的测试代码。 不管你采用的技术是什么,测试装备都应该具有以下功能:
  • 用以指定设置与清理(setup and cleanup)的标准途径
  • 用以选择个别或所有可用测试的方法
  • 分析输出是否是预期(或意外)结果的手段
  • 标准化的故障报告形式
测试应该是可以组合的;也就是说测试可以由子组件的子测试组合到任意深度。通过这一特性,我们可以使用同样的工具、同样轻松地测试系统的选定部分或整个系统。 在测试过程中我们可以临时创建一些特定函数,比如print语句等,但是在调试会话的最后,需要使即兴测试正式化。不要把测试随便扔掉,把它们加入到单元测试中。

构建测试窗口

即使是最好的测试集也不大可能找出所有的bug,这就意味着,一旦某个软件部署之后,常常需要对其进行测试——在现实世界的数据正流过它的血脉时。 含有跟踪消息的日志文件就是这样一种机制。日志消息的格式应该正规、一致。 了解运行中的代码的内部状况的另一种机制是“热键”序列。按下特定的键组合,就会弹出一个诊断控制窗口,显示状态消息等信息。 对于更大、更复杂的服务器代码,提供其操作的内部视图的一种漂亮技术是使用内建的Web服务器。

测试文化

你编写的所有软件都将进行测试——如果不是由你和你的团队测试,那就是由最终用户测试——所以你最好计划好对其进行彻底的测试。
测试你的软件,否则你的用户就得测试。

五、邪恶的向导

开发者为了短期内开发大型应用,往往借助向导,比如Microsoft Visual C++会自动为你生成超过1200行代码。 但是使用别人设计的向导代码并不能帮助你成为专家。这实际上是靠巧合编程,向导就是一条单行单——它们为你制作代码,然后就走了。如果出了问题,还是要自己来修改。 我们并不是反对向导,相反我们在代码生成器中专门讨论了如何编写自己的向导,如果你真的使用向导,却不理解它制作出的所有代码,你就无法控制自己的应用,你没有能力维护它,而且在调试时会遇到很大的困难。
不要使用你不理解的向导代码

Vote Vote Cancel Collect Collect Cancel

<< 上一篇: 第六章:当你编码时(1)

>> 下一篇: 第七章:在项目开始之前