STM32 | 分享几个开源的测试框架

1024G 嵌入式资源大放送！包括但不限于C/C++、单片机、Linux等。关注微信公众号【嵌入式大杂烩】，回复1024，即可免费获取！

这是一篇测试相关的笔记。我们软件开发最终都离不开测试的，可以通过测试来发现很多问题。在这之前先扯谈一波：

在这给还没找工作的朋友提个醒，能找开发的职位就别找测试的职位，除非你真的很喜欢测试。亲身经历，做测试很不好受。测试其实有两类，一种是自己去测自己测的东西，另一种是去测别人做的东西。如果是第一种，我倒是很愿意做，因为我们本质上还是开发工程师，大概80%的工作时间在做开发，20%的工作时间在测自己开发的东西。这个测试的时间值得花，可以通过测试来发现我们在开发过程中没有注意到的点。如果是第二种，我们本质上就是测试工程师了，大概80%的时间在测别人的东西，20%的时间在想着怎么测别人的东西。如果是这一种的话，那我们就只能当别人的配角了。

找工作时，有一点要注意：有些职位写着嵌入式软件工程师，实则测试工程师，这个得问清楚。

回归正题，下面开始我们的这篇笔记：

几个开源的测试框架

框架（framework）是一个框子——指其约束性，也是一个架子——指其支撑性。是一个基本概念上的结构，用于去解决或者处理复杂的问题。 框架这个广泛的定义使用的十分流行，尤其在软件概念。比如我们套用一些测试框架来测试我们写的一些功能函数，的出来的测试结果大概是这样子的：

从输出结果中看，我们可以清晰地看出测试的情况。下面分享几个开源的测试框架：

1、 Unity测试框架

这里的Unity并不是那个游戏开发工具 ，而是一个开源的测试框架。Unity测试框架的项目链接：

https://github.com/ThrowTheSwitch/Unity/releases

目前更新到v2.5.0：

Unity 是一个轻量级的测试框架，它使用 C 语言实现， 代码本身很小 。其代码中大多数是宏定义，所以实际编译后的代码会更小， 比较适合在嵌入式测试应用。

2、 CuTest测试框架

CuTest项目链接：

https://sourceforge.net/projects/cutest/

CuTest是一款微小的C语言单元测试框，只有2个文件，CuTest.c和CuTest.h，全部代码加起来不到一千行。麻雀虽小，五脏俱全，测试的构建、测试的管理、测试语句，都全部包含在内。

3、 Embedded Unit测试框架

Embedded Unit项目链接：

https://sourceforge.net/projects/embunit 

Embedded Unit是个纯标准c构建的单元测试框架，主要用在嵌入式c的单体测试上，其主要特点是不依赖于任何C的标准库，所有的对象都是静态分配。

4、 gtest 测试框架

gtest项目链接：

https://github.com/google/googletest/releases/tag/release-1.8.0

gtest 是 google 公司开发的一个开源的单元测试框架，基于 C++开发，可以对 C++语言和 C 语言进行单元测试。 gtest 有以下特点：

• 提供强大的断言集，支持布尔型、整型、浮点型、字符串以及所有实现了比较运
  算符和输出运算符的自定义类的判断；

• 提供断言扩展功能，当所需要的断言在 gtest 中没有提供时，可以使用 gtest 提供
  的方法进行扩展；

• gtest 会自动收集我们的测试用例，开发者不需要对测试用例进行组织；

• 提供死亡测试的功能，用于测试代码在特定情况下异常崩溃的情况；

• 可将公共的用例初始化和清理工作放入测试夹具中，由 gtest 自动调用；

• 使用参数化自动生成多个相似的测试用例

Unity的使用分享

这里分享Unity在STM32平台上的移植与使用（keil工程）。移植的过程很简单，一般这些测试框架都是打印的方式把测试结果输出。在STM32中 ，我们一般是通过串口输出到串口上位机，所以我们在移植Unity的时候，处理好这个问题就可以用在STM32上了。

首先，把Unity源码目录下的unity.c、unity.h、unity_internals.h三个文件复制至我们的工程目录下，并把unity.c添加到我们的keil工程中，然后添加文件路径：

我们打开unity_internals.h文件，发现其有包含一个头文件unity_config.h：

这个文件是配置文件，我们与平台相关的特性放在这个文件中。而这个文件Unity源码中并未提供，所以需要我们自己建立，我这边新建的unity_config.h文件的内容如下：

主要在这里面放了硬件相关的头文件包含以及两个必要的宏定义。第一个宏定义用于重定向输出至串口，第二个宏定义就是我们的串口初始化。

在unity_internals.h中我们发现unity_config.h文件被条件编译屏蔽掉了，我们需要定义宏把它打开：

最后在我们的main.c中包含头文件unity.h即可使用unity测试框架。在unity_internals.h中有很多可修改的配置，比如在不同的平台中，整数的长度是不一样的，在 Unity 中，允许开发者设置整数的长度。如果没有设置， Unity 指定的默认值是 32 位。我们的STM32就是32位的，所以我们不需要修改。

下面开始编写测试用例。 在 Unity 中，每个测试用例是一个函数， 该函数没有参数和返回值。下面我们来测试一个闰年判断函数：

在测试函数中用到 TEST_ASSERT_TRUE 和 TEST_ASSERT_FALSE ， 是 Unity 实现的两个断言， 用于判断
布尔型表达式的值为真或为假。这些测试框架一般都是用断言来进行测试的，包括以上分享的几个框架都是如此。本例中只用到了两个断言，在 Unity 中还有很多断言，如下是部分断言列举：

Unity 默认需要实现用例初始化函数 setUp 和用例清理函数 tearDown，这两个函数均没有参数和返回值。 在闰年判断函数的测试用例中，由于不需要初始化和清理操作，实现的两个函数如下：

在编写了测试用例后， 接下来就可以在 main 函数中运行测试用例。在 Unity 中，使用宏 RUN_TEST 运行测试用例，参数为要运行的测试用例的函数名称。主函数如下：

UNITY_BEGIN函数就是UNITY初始化函数，我们的串口初始化也是在这里面被调用的：

RUN_TEST函数用于运行我们的测试用例。UNITY_END函数就是返回我们的测试结果。最终，运行得到如下结果：

假如，我们把测试闰年的测试函数里的2000改为2001：

那么输出结果就变为：

可以从结果看出没有通过的用例相关的代码所在行。在进行这样子的测试之前，我们当然得要明白我们的功能函数的功能及其预期输出，我们才能去进行测试用例的设计及进行测试。

以上就是关于Unity测试框架的使用分享，这只是这个测试框架的基本使用。有兴趣的、有用得上的朋友可以自己进行深入研究及使用。

相关书籍

第一本书：《软件单元测试入门与实践》周立功

这个Unity测试框架是我在周立功周工几个月前出版的新书《软件单元测试入门与实践》中看到的。之前刚出版的时候，他们有送书活动，我申请了一本纸质版书籍，没来得及看，最近仔细翻了一下，发现还实用，又学到了很多新东西。这不只是一本讲测试的书，也是一本教我们如何调高软件质量的书。书中有理论和实践大概各占一半，介绍了很多实用的工具和技巧。

前面几章很详细地介绍了一些测试相关的知识，比如黑盒测试、白盒测试、灰盒测试、静态测试，动态测试等。介绍了静态测试工具：pc-lint 编码规则检查工具与 SourceMonitor 代码结构检查工具。其中pc-lint可以集成到keil中进行使用。从某种意义上说，PC-Lint 是一种更加严格的编译器，它除了可以检查出一般的语法错误外，还可以检查出那些虽然符合语法要求，但很可能是潜在的、不易发现的错误。

后面几章分享一些实用工具的使用，比如Unity测试框架、cmake自动构建工具、持续集成系统 gitlab 等。

第二本书：《测试驱动的嵌入式C语言开发》尹哲翻译

这本是在周工那本书的参考文献里的其中一本。

这是老外写的书。看目录好像还不错，有空的时候可以当做课外书来读。

以上就是本次的笔记分享，希望各位喜欢！

本笔记的keil工程及以上两本书的电子档可以关注公众号【嵌入式大杂烩】，回复【unity】进行获取。