c++ - 有没有更简洁的方法来公开测试的实现细节？

Question

我知道有一种流行的观念认为实现细节不保证测试和/或实现应该公开。为了这个问题，请假设测试和最小化 API 都有好处。

应该如何测试内部免费功能？

// Example for C
static MyType do_something_internal(OtherType * X);
// Or (roughly) equivalently
namespace { MyType do_something_internal(OtherType * X); }

我们目前采取的选择是公开调用，但在详细命名空间中:

// Preserve the friendly function name and internal linkage
static MyType do_something_internal(OtherType * X)
extern MyType detail_do_something_internal(OtherType *X)
  { return do_something_internal(OtherType *X); }

// C++ version preserving the external linkage of the original
namespace detail {MyType do_something_internal(OtherType * X);}

我们可以改为公开包含对内部函数的引用的单个对象:

struct exposed_for_test {
  auto detail_do_something_internal = do_something_internal;
  auto detail_other = other;
} // Similar in C, but somewhat less convenient to write out

我们可以将测试接口(interface)包装在预处理器宏中，小心程度不同:

#ifndef TESTING_BUILD
#define LINKAGE extern
#else
#define LINKAGE static
#endif
LINKAGE MyType do_something_internal(OtherType * X)
// or:
#ifdef TESTING_BUILD
static MyType do_something_internal(OtherType * X);
extern MyType detail_do_something_internal(OtherType * X)
{ return MyType do_something_internal(OtherType * X); }
#endif

目前我倾向于最后一种选择。任何调用公开接口(interface)的非测试代码都将无法链接到发布版本中。然而，这似乎不可避免地使编译时间加倍，并且测试与已发布的目标文件不同的目标文件感觉有点不舒服。也许将测试接口(interface)留在原处并依靠链接时间优化将其剥离会更好。

我也在考虑编写与发布代码内联的测试代码，以直接访问静态函数。但是，这将“真实代码”与“测试代码”混为一谈，并且可能是一个有争议的解决方案。

然而，上述所有选项看起来都很粗糙，所以我想问问社区 - 你们有更好的想法吗，或者你赞成以上之一？谢谢。

Answer 1

如果你愿意尽可能“内联”测试代码 在 *_test.cc 文件中包含 *.cc 文件怎么样？ 以我的拙见，辅助函数通常可以在另一个文件中安家，它们是公共(public)实用程序函数。否则，它们对于测试来说太小且微不足道，或者它们的作用没有明确定义。是的，完全有可能没有其他人会使用其他 *_helper_util.h 接口(interface)，但对于很多代码来说都是如此。对吧？