C语言单元测试Unity使用(一) 入门指南

欢迎

Unity是一个单元测试框架。我们的目标是保持它的规模和功能。核心的Unity测试框架有三个文件:一个C文件和两个头文件。它们共同提供函数和宏，使测试更容易。

Unity被设计成跨平台的。它努力坚持使用C标准，同时仍然支持许多嵌入式的、违反规则的C编译器。Unity已经被许多编译器使用，包括GCC、IAR、Clang、Green Hills、Microchip和MS Visual Studio。要让它与新目标协同工作并不难。

文件概述

Unity断言引用

本文将指导您完成Unity提供的所有断言选项。这将是你的单元测试面包和黄油。与Unity的其他部分相比，您将花费更多的时间在断言上。

Unity断言备忘单

此文档包含前一文档中描述的断言的摘要。它是完美的打印和参考，而你熟悉Unity的选项。

Unity配置指南

当你要在一个新的目标或编译器中使用Unity时，这个文档是你要参考的。它将指导您完成配置选项，并将帮助您定制您的测试体验以满足您的需求。

Unity辅助脚本

本文档描述了用于简化测试工作流程的帮助脚本。它描述了可选Ruby脚本的集合，包括在Unity安装的自动目录中。Ruby和这些脚本都不是使用Unity所必需的。它们是为那些希望使用它们的人提供便利。

Unity许可

没有许可文件的开源项目是什么?这个简短的文档描述了您在使用这个软件时所同意的条款。基本上，我们希望它在任何情况下都能对您有用，但是如果您遇到问题，请不要责怪我们。

文件夹概述

如果你已经通过Github或类似的东西获得了统一，你可能会惊讶于你的脸上突然出现了这么多东西。别担心，团结本身是很小的。剩下的只是为了让你的生活更轻松。你可以忽略它或者在你方便的时候使用它。这里是项目中所有内容的概述。

• src - 这是您关心的代码!此文件夹包含一个C文件和两个头文件。这三个文件是统一的。

• docs - 您正在阅读此文档，因此您可能已经找到了进入此文件夹的方法。在这里可以找到所有方便的文档。

• examples - 这包含了一些使用Unity的例子。

• extras - 这些附加功能不是核心项目的一部分，是可选的。如果你通过詹姆斯·格伦宁(James Grenning)的书联系到我们，你会想看看这里。

• test - 这就是Unity及其脚本测试的方式。如果你只是使用Unity，你可能永远都不需要进入这里。如果您是幸运的团队成员，可以将Unity移植到一个新的工具链，这是一个验证所有配置是否正确的好地方。

• auto - 在这里你会发现有用的Ruby脚本来简化你的测试工作流程。它们纯粹是可选的，不需要使用Unity。

如何创建测试文件

测试文件是C文件。通常情况下，您将为要测试的每个C模块创建一个测试文件。测试文件应该包括unity.h和要测试的C模块的头文件。

接下来，测试文件将包括setUp()和tearDown()函数。

• setUp函数可以包含您希望在每次测试之前运行的任何内容。

• tearDown函数可以包含您希望在每次测试之后运行的任何内容。

这两个函数都不接受参数，也不返回任何东西。如果你不需要它们，你可以把它们中的一个或两个都留空。

如果您正在使用Ceedling或者测试运行器生成器脚本，您可以完全关闭它们。不确定吗?试试吧。如果编译器在链接时报错说它找不到setUp或tearDown，那么您就会知道至少需要为它们包含一个空函数。

文件的大部分将是一系列测试函数。测试函数遵循以 test_ 或 spec_ 开头的惯例。您不必这样命名它们，但是它清楚地说明了哪些函数是针对其他开发人员的测试。此外，与Unity或Ceedling一起提供的自动化脚本将默认寻找以这种方式添加前缀的测试函数。测试函数不接受任何参数，也不返回任何结果。所有的测试会计都在Unity内部处理。

最后，在测试文件的底部，您将编写一个main()函数。这个函数将调用UNITY_BEGIN()，然后为每个测试调用RUN_TEST，最后调用UNITY_END()。这实际上会触发每个测试函数运行，因此每个函数都有自己的RUN_TEST调用是很重要的。

记住要将每个测试添加到主函数中可能会很繁琐。如果您喜欢在构建过程中使用帮助脚本，您可以考虑使用我们的便利的generate_test_runner.rb脚本。这将为您创建主函数和所有调用，假设您已经遵循了建议的命名约定。在这种情况下，根本不需要在测试文件中包含主函数。

完成后，您的测试文件将如下所示:

#include "unity.h"
#include "file_to_test.h"

void setUp(void) {
    // set stuff up here
}

void tearDown(void) {
    // clean stuff up here
}

void test_function_should_doBlahAndBlah(void) {
    //test stuff
}

void test_function_should_doAlsoDoBlah(void) {
    //more test stuff
}

// not needed when using generate_test_runner.rb
int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_function_should_doBlahAndBlah);
    RUN_TEST(test_function_should_doAlsoDoBlah);
    return UNITY_END();
}

最终，您可能需要更多的定制。对于这类事情，你需要看一下配置指南。不过，这应该足以让你开始了。

运行测试函数

为测试运行程序编写自己的main()函数时。有两种执行测试的方法。

经典的变体

RUN_TEST(func, linenum)

或者更简单的替换从函数的开头开始。

RUN_TEST(func)

这些宏在调用测试之前执行必要的设置，然后处理清理和结果列表。

忽略测试函数

有时，一个测试由于某些原因是不完整的或无效的。在这些时候，可以调用TEST_IGNORE。控件将立即返回给测试的调用方，并且不会返回任何故障。这在自动生成测试运行程序时非常有用。

TEST_IGNORE()

忽略这个测试并立即返回

TEST_IGNORE_MESSAGE (message)

忽略这个测试并立即返回。输出一条消息，说明为什么忽略测试。

流产的测试

有时，一个测试将包含对错误条件的无限循环，或者可能有理由在不执行测试其余部分的情况下提前退出测试。在Unity中有一对宏支持这个功能。第一个TEST_PROTECT设置特性，并处理紧急中止情况。然后可以在测试中的任何时候使用TEST_ABORT来返回到最后一个TEST_PROTECT调用。

TEST_PROTECT()

设置并捕获宏

TEST_ABORT()

中止测试系统
例子:

main()
{
    if (TEST_PROTECT())
    {
        MyTest();
    }
}

如果MyTest调用TEST_ABORT，程序控制将立即返回TEST_PROTECT，返回值为0。

如何构建和运行测试文件

这是学习新的单元测试框架的最大挑战，至少在C或c++这样的语言中是这样。这些语言真的很擅长让你“接近金属”(为什么这个短语是金属?)说“接近硅”不是更准确吗?虽然这个特性通常是一件好事，但是它会增加测试的挑战性。

您有两个非常好的工具链选项。根据您来自何处，您可能会惊讶地发现这两个选项都没有在您的硬件上运行单元测试。原因有很多，但这里有一个简短的版本:

• 在硬件上，你有太多的约束(处理能力、内存等)，

• 在硬件上，你不能完全控制所有的寄存器，

• 在硬件上，单元测试更具挑战性，

• 单元测试不是系统测试。让他们分开。

与在实际硬件上运行测试不同，大多数开发人员选择将它们作为本地应用程序(例如使用gcc或MSVC)或作为在模拟器上运行的应用程序来开发。两者都是不错的选择。本地应用程序具有更快、更容易设置的优点。模拟器应用程序的优势是使用与目标应用程序相同的编译器。配置这些的选项在配置指南中进行了讨论。

要使其中之一工作，您可能需要对包含您的寄存器集的文件进行一些更改(稍后讨论)。

在这两种情况下，测试都是通过链接unity、测试文件和被测试的C文件来构建的。这些文件创建了一个可执行文件，可以作为该模块的测试集运行。然后，对下一个测试文件重复这个过程。这种将测试分离为单个可执行文件的灵活性使我们能够更彻底地对系统进行单元测试，并将所有测试代码排除在最终版本之外!