单元测试读取数据库失败是啥原因

Posted 2023-05-15

参考技术A 情况有多种。
第一、数据库的服务没有正常启动。
第二、数据库的TCP/IP协议没有启动。
第三、如果是是客户端链接服务器时电脑的防火墙没有关闭，被防火墙拦截了。

make / gcc：“错误构建”的可能原因是啥？ [关闭]

【中文标题】make / gcc：“错误构建”的可能原因是啥？ [关闭]

【英文标题】：make / gcc: What are possible causes of a "bad build"? [closed]make / gcc：“错误构建”的可能原因是什么？ [关闭]

【发布时间】：2017-02-16 17:24:52

【问题描述】：

我有一些单元测试由于一些数学计算返回意外结果而失败。

已知代码本身是正确的。 构建系统没有改变 编译器标志没有改变

我们使用 cmake 来生成我们的 makefile，这让我确信 makefile 是正确的。

构建已经运行了好几个月，只是这个特殊的、不寻常的、虚假的失败，因此提出了这个问题。

我查看了失败测试的目标文件，正如预期的那样，它比源文件更新，所以 make 认为它不需要重新构建它。

-rw------- 1 steve steve 64578    Feb  7 11:13 foo_tests.cc
-rw------- 1 steve steve 12930760 Feb 14 13:18 foo_tests.cc.o

如果我删除目标文件并重新构建，测试现在就通过了。

-rw------- 1 steve steve 12931080 Feb 16 13:57 foo_tests.cc.o

我注意到新的目标文件稍大一些。这有点令人费解。

什么会导致这样的错误构建？

在运行错误构建并发现虚假错误之前，我可以做些什么来检测它？

构建细节：

这是一个发布模式二进制文件，其 makefile 使用 cmake 生成，并在 Centos 7.2 上使用 gcc 5.2.1 构建

我们使用的编译器标志是：

CXX_FLAGS
-Werror
-Wall
-Wextra
-m64
-msse2
-msse4.2
-mfpmath=sse
-ftemplate-depth-128
-Wno-unused-parameter
-Wno-maybe-uninitialized
-Wno-strict-aliasing
-pthread
-DBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG
-ggdb2
-DNDEBUG
-O3
-funroll-loops
-fdevirtualize
-finline-functions
-fno-builtin-malloc
-fno-builtin-calloc
-fno-builtin-realloc
-fno-builtin-free

LINKER_FLAGS:
-m64
-rdynamic

【问题讨论】：

“在运行错误构建并发现虚假错误之前，我能做些什么来检测它吗？” 一些构建系统允许进行 空运行 i>.

投票结束太广泛了。有太多事情会导致构建中断。

可能.cc 文件使用的某些头文件已更改，但您的makefile 并未将头文件列为.o 文件的先决条件。也许您的源文件上的时间戳被错误地重置为某个较旧的值，或者.o 文件上的时间戳被错误地更新而没有重建它。如果没有看到您的 makefile 和/或不了解您的设置，这是不可能的。

@MadScientist 我们使用 cmake，并且正确列出了依赖项，我很确定。该构建已经工作了几个月，没有对 CMakeLists 进行任何更改，只是这个特殊的、不寻常的、虚假的失败，因此问题

那么最有可能的罪魁祸首是有人以某种方式弄乱了您文件上的时间戳。或者，在 CMake 生成的 makefile 中存在一个问题，这似乎不太可能，除非您在生成源文件或头文件的地方进行了复杂的设置。

【参考方案1】：

什么会导致这样的糟糕构建？

最可能的原因是源代码错误，其中“错误”可能只是意味着过时。如果您的makefile 没有表达所有 每个目标的依赖关系，那么make 可能在某些组件确实需要重建时无法重建它们。结果可能是一组无法正常协同工作的目标文件。

另一种可能性是编译器选项错误或不一致。如果您的程序的行为取决于编译器选项（符号定义在这里特别可能是罪魁祸首），并且您使用错误的选项构建组件，那么更改选项通常不足以说服make 重新构建任何东西。在这种情况下，干净的构建是最好的策略。

鉴于您的“坏”构建仍然会生成可以链接到工作（尽管不正确）程序的对象，并且删除对象文件并使用相同的工具链重建它会导致具有不同行为的不同对象文件，我没有看到任何其他可能的选择。

在运行错误构建并发现虚假错误之前，我可以做些什么来检测它？

假设构建实际上首先成功，不。这是测试适合的事情之一。但请注意，由于我描述的任何一种问题，执行失败的构建是生成成功但糟糕的构建的入口点。

【讨论】：

我相信所有依赖项都正确列出，因为构建已经工作了几个月，没有对构建系统、编译器标志或其他进行任何更改。我们使用 cmake，我希望在创建目标和链接依赖项等时获得正确的依赖项。我过去也注意到，当我更改编译器标志时，cmake 会导致所有受影响的目标被认为是过时的。正是这种特殊的、不寻常的、虚假的失败，因此是问题所在。

@SteveLorimer，对我来说，最重要的是“坏”构建产生了一个明显有效的目标文件，因为它可以链接到一个可运行的可执行文件，但只会产生不正确的结果。除了测试之外，没有什么好的方法可以检测出这种错误的构建，因为代码的运行时行为是唯一表明它有什么问题的东西。

好的，感谢您的意见。非常令人费解！