我希望对我的程序（使用C语言编写）进行单元测试，因为我知道这样做的好处，它能够显示出问题所在。
我也喜欢黑盒测试，因为它可以告诉我程序是否正常工作（至少在测试中是这样的）。
目前，我正在使用Autotest（随Autoconf一起提供）来进行测试，以避免添加依赖项。
现在，我不介意使用更好的框架，但问题是我不想为黑盒和单元测试使用不同的框架。是否可能从单元测试框架中运行黑盒测试？我真正想要的是良好的日志输出，精确地指出出了什么问题以及在哪里。
我的另一个选择是使用Autotest进行单元测试。问题是没有框架。我编写了一个小的“测试驱动程序”，接受要测试的函数名称和传递给该函数的参数，并调用该函数。问题是我不确定在断言和输出函数返回值之间要使用什么边界（出于日志记录目的，因为我喜欢Autotest将为我提供差异）。由于大多数函数返回列表，因此使用预期输出（使用Autotest的expout）进行比较会更快。
是否可以从单元测试框架运行黑盒测试？
是的，您可以在单元测试中使用system()调用Autotest，然后对返回值进行断言。
但我不建议这样做，因为单元测试经常执行，它们应该非常快，即以秒为单位而不是以分钟为单位。
单元测试和集成测试（您称之为黑盒测试）有不同的目的：单元测试通过测试验证代码中的“单元”（无论这意味着什么，函数或函数集群）是否按预期工作，而集成测试则覆盖整个程序，将其作为一个整体进行验证。
因此，通常情况下，在代码进行了几次更改后会运行单元测试，特别是如果您应用TDD，则会执行集成测试。
我宁愿拥有一个典型的带有断言的单元测试程序以及一个集成套件，该集成套件将在您的黑盒测试中调用单元测试。
问题在于我不确定在断言和输出函数的返回值之间使用哪个边界（出于日志记录目的，因为我喜欢Autotest如何给我提供差异）。
使用断言时没有任何输出：如果预期值和实际值相等，则什么也不会发生，否则单元测试框架将打印出错误消息（预期为X，实际为Y）。 让计算机来完成测试工作。
使用日志记录输出差异时，仍需手动（视觉上）检查差异的结果（例如：列表中是否缺少一个项目或多个项目...）。
由于大多数函数返回列表，因此使用预期输出（使用Autotest的expout）进行准备更快。
您可能需要编写一个使用断言比较列表的函数。
