你写的程序很健壮？不妨测一下？

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

在这给还没找工作的朋友提个醒，能找开发的职位就别找测试的职位，除非你真的很喜欢测试。亲身经历，做测试很不好受。

测试其实有两类，一种是自己去测自己测的东西，另一种是去测别人做的东西。

如果是第一种，我也很愿意做，因为我们本质上还是开发工程师，大概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 实现的两个断言， 用于判断 布尔型表达式的值为真或为假。关于断言的笔记可查阅：【C语言笔记】assert()怎么用？

这些测试框架一般都是用断言来进行测试的，包括以上分享的几个框架都是如此。本例中只用到了两个断言，在 Unity 中还有很多断言，如下是部分断言列举：

Unity 默认需要实现用例初始化函数 setUp 和用例清理函数 tearDown，这两个函数均没有参数和返回值。

在闰年判断函数的测试用例中，由于不需要初始化和清理操作，实现的两个函数如下：

在编写了测试用例后， 接下来就可以在 main 函数中运行测试用例。

在 Unity 中，使用宏 RUN_TEST 运行测试用例，参数为要运行的测试用例的函数名称。主函数如下：

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

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

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

那么输出结果就变为：

可以从结果看出没有通过的用例相关的代码所在行。

在进行这样子的测试之前，我们当然得要明白我们的功能函数的功能及其预期输出，我们才能去进行测试用例的设计及进行测试。