C/C++单元测试理论精要（一）
内容介绍
本系列文章根据《单元测试与VU2.6应用》视频讲座的理论部分整理而成，主要讨论四个问题：为什么需要单元测试？怎样征服可测性难题？怎样才能高效率测试？怎样保证测试效果？重点阐述单元测试的关键问题，不是一般概念，适合于对单元测试有一定了解的读者。
在选择工具和实施单元测试前，我们应该对相关理论有一个系统的了解，特别是将会遇到哪些难题，如何解决，要心里有数，否则的话，很可能劳民伤财，半途而废。如果只会测试加法函数或者三角形函数之类的独立小程序，就以为可以做单元测试了，那就像一个人刚学会走路，就去长途跋涉。
本文介绍的是针对企业项目的单元测试。企业项目具有两个特点：项目复杂，时间紧张。项目复杂，意味着测试时会遇到很多难题；时间紧张，要求我们不但要保证测试效果，还要尽可能高效率。本文不是泛泛而谈，而是针对企业项目的两个特点，努力揭示本质性的问题，并提出解决办法，对于常识性的问题，将比较简略的带过。使用的工具是Visual Unit 2.6，本文主要不是介绍工具，而是介绍问题所在和解决办法，涉及到工具，只是为了具体的展示解决办法，也为了说明，这些办法都是可行的，并非空谈。
第1章 为什么需要单元测试？
1.1 从代码特性看单元测试的必要性
代码有一个很基本的特性，是什么呢？对数据分类处理。一个判定，就是一次分类。如果判定中又嵌套了判定的话，分类次数就会翻倍。循环判定也是一种分类。
如果一个分类遗漏的话，也就是说，某种输入没有处理，会怎么样呢？一个Bug诞生了！如果一个分类的处理不正确，又会怎么样呢？又一个Bug诞生了！
一个函数要做到没有错误，要保证两点：分类完整，也就是各类可能输入都要考虑到；
处理正确，也就是每一类输入都要进行正确的处理。做到了这两点，就可以说，函数的功能逻辑是正确的。函数的功能逻辑就是对数据的分类以及处理。
那么，怎样才能全面地检测程序的功能逻辑呢？调试，是临时的，不做记录，另一方面，调试的工作方式是拦截数据，并不是所有输入分类都能拦截得到的，如果一个函数有十类输入，调试能覆盖五六个就不错了。系统测试，不针对具体的函数，无法做到对具体函数的输入分类覆盖。要全面地检测程序的功能逻辑，必须把输入分类全部列出来。并检测程序是否处理了这些输入，处理是否正确。这就是单元测试。
相关文档：
C 调用 Fortran
c2ffn.f
SUBROUTINE NAMEAGE(NAME, NLEN, AGE, TEMP)
CHARACTER*(*) NAME
INTEGER NLEN,AGE
REAL TEMP
C
WRITE(6,1000) NAME(1:NLEN),AGE,TEMP ......
在使用回调函数中，往往会设置一个指向函数的指针，那为什么不直接将函数名作为参数传递呢？
原因是：在C语言中函数本身不是变量，但是可以定义指向函数的指针。这种类型的指针可以被赋值、存放在数组中、传递给函数以及作为函数的返回值，
下面是我在网上找到的一个关于回调函数的小例子（对原文的例子有所修改）
原文� ......
#include <unistd.h>
#include <fcntl.h>
#include
<sys/types.h>
#include <sys/ioctl.h>
#include
<stdlib.h>
#include <stdio.h>
#include
<linux/soundcard.h>
/* 下面的三个参数是跟具体文件相关的，文件什么样，就要设置成什么样 */
#define RATE 11025&nbs ......
linux是一个复杂的软件系统，其内核源代码往往会用到一些在应用程序设计中部常见语言成分和编程技巧，这些都是分析内核源代码的基本功，希望大家能重点掌握。
首先，gcc编译器从语言里吸收了“inline”和“const”。inline函数的大量使用，有利于提高运� ......
