在 Symbian S60 平台进行单元测试

核心提示：1 class CMapExampleSmsEngine : public CBase,2 public MMsvSessionObserver34 #ifdef __SYMBIANOSUNIT5 {6 friend class CMapExampleSmsEngineTest;7 #endif8 ...9 }10由测

1 class CMapExampleSmsEngine : public CBase,

2 public MMsvSessionObserver

3

4 #ifdef __SYMBIANOSUNIT

5 {

6 friend class CMapExampleSmsEngineTest;

7 #endif

8 ...

9 }

10

由测试目标类衍生一个封装类，并对其使用可在实类里成为保护类属性的函数。测试时在类里或者类函数里使用预编译，使其提供更多灵活的类属性方式。注意代码会因为预编码时存在的比较差的可读性而出现不同的断点甚至引起很难处理得新的错误。

接下来的一章将会介绍理论上的单元测试并提供开发单元测试时需要牢记得策略和技巧。

理解可测试性

是什么决定软件是可测试的还是不可测试的呢?通过检查现有的函数(如上一章介绍的)，我们很容易可以看出在程序中添加测试程序的早晚将会产生不同的效果，如果程序的内部结构是复杂的，开发者就不必存取数据、函数和事件处理系统(当使用异步接口时)。

Pressman[7]定义了以下几条使软件更具测试性的原则：

可操作性：软件对象越易操作，就越具有可测试性。所以在默认状态下，尽可能不让代码过于膨胀冗余，及早地去除bug(在它们让你的程序死掉之前)。

可观察性：所见即所测。缺失的源代码或是文档将会让我们很难判断如何测试对象。不可实现的属性也将使我们很困难甚至不可能确定结果是否正确。异常和错误条件以及它们的输出都应该是有根据的以便于我们能判断我们的操作是否是我们想要的。

可控制性：尽可能保证函数开源以便测试能够很容易地控制测试对象。实际上，较长的代码缺失和复杂的函数使它们成为共有类或保护类。软件使用的数据需是测试程序中可实现可改变的部分。

可分解性：通过控制测试范围分割问题。软件是由很多小段代码组成的，这些小段代码可拿来独立测试。实际上，一个测试实例应测试一个类，所有的依赖性都应该能被小段代码和模拟对象所替代。

简易性：代码越少，要用的测试越少。系统里不应该存在没有用到的功能函数(删除死码)。软件结构应该是简单且模块化的。代码应该尽可能短，应具有可读性，不存在任何没用的控制架构。

稳定性：改动越少意味着测试所受的干扰越少。软件的改动应该是有计划可控制的。设计(和测试)的软件是用来将程序从运行失败状态恢复正常。Pressman建议缩减代码和测试的改动，然而那些思维活跃的开发者更喜欢不停地反复修改(改动代码，测试并删除不必要的代码)。