我可以为基于 ac 的 mcu 项目使用什么单元测试框架?

电器工程 测试 openocd
2022-01-21 15:04:14

我正在考虑如何在我的 mcu 项目中使用单元测试,以及我可以使用哪些框架来简化它。

今天我在 Linux pc 上使用带有 OpenOCD-jtag 的 stm32,它全部由经典的 Makefile 控制并与 gcc 交叉编译。

我可以自己创建一些东西,但是如果有一个我可以使用的框架,那就太好了。(如果框架可以以 Jenkins/Hudson 可以读取的格式输出结果,那将是一个奖励)。

有没有办法使用带有 stm32 的单元测试框架?

4个回答

有很多变量将决定在您的情况下使用的最佳单元测试框架。一些可能会影响您的选择的项目将是:

  • 目标语言。
  • 有哪些库支持可用。例如 libc 或其精简版。
  • 目标的操作系统。例如无、FreeRTOS、自定义。

大多数 xUnit 类型框架将提供一些可能有用的基本功能。我过去使用Cunit取得了一些成功。(Ubuntu/Debian 上的 libcunit1-dev 软件包)。大多数框架都需要 libc 可用,有些则需要额外的操作系统支持。

另一个只有 3 行长的替代方案是Minunit

我发现使用微控制器作为目标的单元测试非常麻烦,因为您需要能够提供一个适合下载测试、运行它们然后返回结果的环境。只是让平台到位,使您能够做到这一点是一项艰巨的任务。

我采用的另一种对我有用的方法是在主机上进行单元测试,在驱动程序和应用程序代码之间实现一个抽象层。由于您使用 gcc 作为目标,因此代码也应该在主机上编译。

在编译主机上进行测试通常要容易得多,因为您拥有主机操作系统及其所有工具的完整支持。例如,在主机上进行测试时,我有一个模拟版本的无线驱动程序,它与在目标上运行的真实驱动程序具有相同的接口。主机版本使用 UDP 数据包来模拟无线数据包传输,模拟驱动程序支持丢弃数据包的能力,因此我可以测试我的协议。

在我正在开发的产品中,使用了线程操作系统,因此在主机操作系统上进行测试的抽象层使用了 pthreads。

虽然并不完美,但您编写和运行测试越容易,您实现更多测试用例的可能性就越大。让代码在不同平台上运行的另一个好处是测试代码是否可移植。如果目标和主机架构不同,您将很快发现字节序错误。

我现在有点跑题了,但觉得这些想法可能有助于您选择测试框架和测试方法。

查看 CppUTest 和 James Grenning 的优秀http://pragprog.com/book/jgade/test-driven-development-for-embedded-c

CppUTest 支持 C 和 C++,它有一套很好的 Makefile 模板,让我很快就开始了。

查看 embUnit http://embunit.sourceforge.net/embunit/index.html它是一个占用空间小的嵌入式 C 单元测试框架。

我们在几个嵌入式微控制器项目中成功使用了它。不要期望使用桌面单元测试框架获得的选项和功能。但它绝对足够强大。

它为您定义了许多断言,因此您不必像使用 minUnit 那样浪费时间编写自定义断言。

前段时间我写了一篇关于这个主题的详尽教程:Unit-testing (embedded) C applications with Ceedling我在一堆项目中使用了这些技术,到目前为止我很高兴。