良好的编程习惯 （六）代码的可测试--断言的使用

6-1：在进行集成测试/ 系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细
分析并优化测试用例，以提高测试效率。
说明：好的测试用例应尽可能模拟出程序所遇到的边界值、各种复杂环境及一些极端情况
等。

6-2 ：使用断言来发现软件问题，提高代码可测性。
说明：断言是对某种假设条件进行检查（可理解为若条件成立则无动作，否则应报告），
它可以快速发现并定位软件问题，同时对系统错误进行自动报警。断言可以对在系统中隐
藏很深，用其它手段极难发现的问题进行定位，从而缩短软件问题定位时间，提高系统的
可测性。实际应用时，可根据具体情况灵活地设计断言。
示例：下面是C 语言中的一个断言，用宏来设计的。（其中NULL 为0L）
#ifdef _EXAM_ASSERT_TEST_ // 若使用断言测试

void exam_assert( char * file_name, unsigned int line_no )
{
printf( "\n[EXAM]Assert failed: % s, line %u\n",
file_name, line_no );
abort( );
}

#define EXAM_ASSERT( condition )
if (condition) // 若条件成立，则无动作
NULL;
else // 否则报告
exam_assert( __FILE__, __LINE__ )

#else // 若不使用断言测试

#define EXAM_ASSERT(condition) NULL

#endif /* end of ASSERT */


6-3：用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。


6-4：不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
说明：断言是用来处理不应该发生的错误情况的，对于可能会发生的且必须处理的情况要
写防错程序，而不是断言。如某模块收到其它模块或链路上的消息后，要对消息的合理性
进行检查，此过程为正常的错误检查，不能用断言来实现。


6-5：对较复杂的断言加上明确的注释。
说明：为复杂的断言加注释，可澄清断言含义并减少不必要的误用。


6-6：用断言确认函数的参数。
示例：假设某函数参数中有一个指针，那么使用指针前可对它检查，如下。
int exam_fun( unsigned char *str )
{
EXAM_ASSERT( str != NULL ); // 用断言检查“假设指针不为空”这个条件

... //other program code
}


6-7：用断言保证没有定义的特性或功能不被使用。
示例：假设某通信模块在设计时，准备提供“无连接”和“连接” 这两种业务。但当前
的版本中仅实现了“无连接”业务，且在此版本的正式发行版中，用户（上层模块）不应
产生“连接”业务的请求，那么在测试时可用断言检查用户是否使用“连接”业务。如下。


#define EXAM_CONNECTIONLESS 0 // 无连接业务
#define EXAM_CONNECTION 1 // 连接业务

int msg_process( EXAM_MESSAGE *msg )
{
unsigned char service; /* message service class */

EXAM_ASSERT( msg != NULL );

service = get_msg_service_class( msg );

EXAM_ASSERT( service != EXAM_CONNECTION ); // 假设不使用连接业务

... //other program code
}


6-8：用断言对程序开发环境（OS/Compiler/Hardware ）的假设进行检查。
说明：程序运行时所需的软硬件环境及配置要求，不能用断言来检查，而必须由一段专门
代码处理。用断言仅可对程序开发环境中的假设及所配置的某版本软硬件是否具有某种功
能的假设进行检查。如某网卡是否在系统运行环境中配置了，应由程序中正式代码来检查；
而此网卡是否具有某设想的功能，则可由断言来检查。
对编译器提供的功能及特性假设可用断言检查，原因是软件最终产品（即运行代码或机器
码）与编译器已没有任何直接关系，即软件运行过程中（注意不是编译过程中）不会也不
应该对编译器的功能提出任何需求。
示例：用断言检查编译器的int 型数据占用的内存空间是否为2，如下。
EXAM_ASSERT( sizeof( int ) == 2 );