大家观点
既然单元测试是如此重要，那为什么不是每一个项目都做了呢？可能是因为即使是简单的测试案例也需要一定的工作量。
回想一下前文讲到的简单的例子。首先，函数的自变量不一定是简单类型。它们也可能是复杂的，所以需要初始化以便于测试。第二，被测功能不一定返回简单类型，也可能是外部变量。最后，“foo”函数可能调用另外一个“goo”。这就好比，硬件传感器/文件/数据库/网络接口/ USB端口接收GUI的用户输入，这会因为分离而不能正常运作。
要为这个特别的“foo”准备一个有用的单元测试用例需要大量的工作。要使所测试功能的所有变量初始化正确，存根/驱动器不可以调用函数（例如“goo”），也不能只能后置条件校验，等等。最后是准备一个美观的报告展示测试执行结果，还有执行过程中涉及的线/陈述或分支。这些资料需要一直保存。
你会觉得这些工作量很大，而且事实上也是。这就是有些软件项目没有进行单元测试的最主要的原因。
嵌入式单元测试实践
在嵌入式软件开发的背景下，单元测试是一个更大的挑战。一方面，它很简单，因为只使用C语言——当使用C ++时，它仅是其中一个简化的子集。另一方面，单元测试用例需要部署在目标板上，或在模拟器上。代码要和所有的测试用例、测试数据一起转移到目标板上，然后执行。最后，试验结果必须收集并传送回主机，以方便进行分析。这些准备工作增加了嵌入式软件进行单元测试的花费。本文我们不使用这样的方法，而是探讨一种更实用的方法。
被测系统
让我们考虑简化的ASR (Acceleration Slip Regulation) 系统，它运行在Keil评估板MVBSTM32E上。必须强调的是，我们提出这样的系统是为了说明一个概念：ASR不是真实存在的软件。
在示例系统中，前轮有两个速度探测监视器。如果一个轮子开始旋转而另一个减慢，则系统假定车轮打滑。接着，系统启动前轮刹车，以便扭矩直接通过前轮轴降低速度。ASR系统工作的真实详情，请参考维基百科en.。
简化的ASR由MDK-ARM建成并通过ULINK Pro部署。它附着在一个汽车模型上运行。该汽车模型装有速度传感器板，并可以模拟滑移条件。如下图。
想了解这些系统是如何工作的，请点击视屏观看。
你们注意到视屏中，当一个车轮上升时，它就失去了抓地力并获得整个扭矩。你可以看到系统如何启动车轮的刹车，使扭矩传递到另一个轮子上。
为了准备ASR的单元测试，我们需要：
- 将uVision项目导入C++test
- 配置里面的C++test项目
- 配置结果传输
- 处理目标边界
- 准备测试套件和示范性测试用例
- 部署并收集结果
完成了这些步骤，我们就可以开始测试的具体工作了。
