如果不考虑从外部调用某些符号，则可以将它们隐藏在共享库中。但是，虽然库的客户端不需要这些符号，但测试可能需要它们。
我一直在使用的解决方案是在CMake“build_tests”中引入一个变量，如果它是
ON还有哪些其他方法可以解决这个问题，它们之间的比较如何？ （他们做了什么权衡？）
我的解决方案是在CMAKE“build_tests”中引入一个变量，如果它是ON，那么符号就不会被隐藏。
这样做的缺点是，对于单个生成的构建系统，您基本上必须在您希望发布的内容（根据需要显示符号）和可用于测试的内容之间做出选择。您必须生成一个用于测试的构建系统，以及一个用于发布的构建系统（如果我理解正确的话），这似乎并不理想。如果您创建了一个仅使某些内容对测试构建可见的可见性宏，则会出现同样的非理想情况。
有人在评论中提出，有些人认为不需要测试内部结构——只有库接口的一部分才需要/应该进行测试。我认为测试不属于库界面的库的较低级别部分可能很有用。
事实是，对于单个生成的构建系统中的单个共享库目标，每个符号要么可见，要么不可见。因此，如果您只想拥有一个生成的构建系统，您可以在其中构建共享库而不影响从中可见的内容，而且还能够测试其内部结构，则需要更改构建共享库的方式，或者改变构建测试可执行文件的方式。
什么是实用的取决于你的图书馆的特点和你想测试的内部。
你可以尝试将你的内部逻辑重构到它自己的静态库中，并让你的共享库包装静态库。然后共享库将是您项目的用户使用的，而静态库将是您用于测试的，在那里您不受任何可见性机制的限制。您要测试的二进制文件将是链接到静态库的测试可执行文件，因此如果您使用任何优化进行构建，某些内容如何转换为机器代码等方面可能会有差异。请注意这一点。这种方法可能需要更多的编程工作来进行分离和包装。
您可以考虑的另一件事是将实现库内部逻辑的特定源文件添加到专用测试可执行文件（或各种源文件的多个测试可执行文件）中。如果您的内部源文件相互独立，这可能是实用的。如果您不使用链接时优化并且您想要真正精细地做事，使用许多测试可执行文件 - 例如 - 每个源文件一个，这可能会比前面提到的使用静态库的方法花费更多的编译时间- 同样，差异的细节将取决于您的项目的特点。有一些测试库旨在支持在与源代码相同的文件中编写测试来帮助您解决这个问题，例如 doctest.
我不太确定这些大规模的想法是否是好主意，因为我没有大型项目的经验。