代码的可测性

arlenexhl

具有良好整体结构的代码，应该符合"低耦合"的特性，形象地说，就是"各家自扫门前雪、不管他人瓦上霜"，每一个函数、每一个类、每一个模块，都应该只做自己该做的事，不要把应该由"其他人"做的事扯进来。 通常，"低耦合"的代码具有可测性，具有不当高耦合特性的代码通常不具可测性，一般来说，如果代码不具可测性，那么加入测试工程后，会产生编译错误，导致测试无法进行。
    高质量代码应该具有正确性、可测性、可复用性、可扩展性。可测性是最基本特性，能测试才能检验和提高正确性，具备了可测性，也就具备了最基本的可复用性和可扩展性。解决不当耦合的 较好手段是重构，即改良代码结构，这样不但能顺利完成测试，更重要的保证了代码具有良好的整体结构，使代码易于维护和复用。
    用打桩来解决可测性问题也是一种思路。打桩是单元测试的常用技术，可用以将影响测试的外部系统隔离：一是将不可控的、费时的实际系统隔离，例如访问网络、数据库、硬件等，二是将复杂的底层系统隔离，采用相对简单的模拟系统来代替，但用打桩尤其是工具自动打桩来解决不当耦合造成的可测性问题，则不见得实用，举个例子来说明：

    void Sort(int[10] data)
    {
        …
        Swap(int[a], int);
        …
    }

    Sort是排序函数，调用了Swap实现两个数的交换，假如用一个自动生成的桩来代替Swap，那么这个桩通常是什么也没做，只是能通过编译而已，这样，两个数的交换过程根本就没有完成，整个Sort函数的功能完全不同了，这样的测试，除了看一下程序是否会崩溃之外，还有什么意义呢？要做到打桩后不改变代码的功能，并非易事，并且打桩并未改良产品代码的结构，还是重构更有价值，下面是几种典型的不当耦合及重构方法：

    把代码写在界面类中
    问题：如果把业务代码写在界面类中，测试时把界面类加入测试工程，会产生编译错误。
    解决：把业务代码独立出来，写到相应的实体类中，对这些实体类进行测试。界面类只负责数据的显示和接受用户的输入，具体的计算由实体类负责。
    说明：把业务代码写在界面类中，这些代码将很难管理和维护，复用就更谈不上了，这是一定要避免的。

    实体类混合了边界代码
    问题：例如，一个表示用户的类CUser，它的对象的数据保存在数据库中，如果在CUser类中直接读写数据库，就是实体类混合了边界代码，这也是一种不当耦合，测试CUser类时要察看数据库，或者要打桩，甚至会产生编译错误。
    解决：把执行数据库操作的代码写到CDatabase类中，CUser类和CDatabase类没有任何关联，由界面类或用于协调各对象工作的控制类来操作这两个类的对象进行数据读写，现在对CUser类的测试就完全和数据库无关了。
    说明：经过重构后，代码的可扩展性、可复用性都有了很大提高，也便于进行单元测试和将来的维护。

    无意中形成了高耦合
    问题：例如，CMyClass类中一个函数中有这样的语句:
    CDemoApp* pApp = (CDemoApp*)AfxGetApp();
    UNIT var = pApp->GetXXX()->Getxxxx();
    由于CDemoApp是工程的最高层类，可能跟工程中的所有类关联，这两行代码就造成被测试对象跟工程中的所有类耦合。耦合具有扩散性，纵向来说，CMyClass类的所有子类也可能跟工程中的所有类关联，横向来说，所有使用了CMyClass类的类，也可能跟工程中的所有类关联，从而形成了盘根错节的关系。这种问题往往很难发现，但把代码加入测试工程后，一般来说是通不过编译的，从而使问题暴露。
    解决：修改被测试代码，去除耦合。把需要从pApp指针中取得的数据改为由参数传进来，这两行代码移到客户程序(即调用被测试函数的代码)中，如果客户程序也是实体类，则继续往上移，直到界面类。
    说明：这类无意中形成的耦合非常常见，一般的代码审查、静态扫描都很难发现这类问题，但把代码加入测试工程后，编译器却能轻松发现。这类问题只要及时发现了，消除并不难，经过简单的代码重构，就可以有效地提高代码质量，特别是提高代码的可复用性，也使单元测试可以顺利进行。

    开发工具生成的代码形成了不当耦合
    有时候，开发工具生成的代码也形成了不当耦合，例如，VC6.0生成的类代码中，源文件会添加下面的代码：
    #include "ProjectName.h" //ProjectName是工程名
    如果在另一个不同名的工程中复用代码，这一行就会产生编译错误。进行单元测试时，这一行形成的不当耦合也可能会导致编译错误，因此应删除它。