specload测试失败非常明确：

reason: : App '/home/jenkins/workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA/libelektra/obj-x86_64-linux-gnu/bin/elektra-specload-testapp' doesn't exist or is not executable

对于quickdump我不能确切地说出了什么问题，但它在elektraQuickdumpSet的某个地方失败了。 在setKey中应该设置了一个错误，但我认为它没有被记录（这可能应该被改变）。

不知道，为什么gopts失败了。 由于没有打印错误消息，我怀疑 testapp elektra-gopts-testapp无法执行（这是唯一不会打印错误消息的情况）。 它也符合specload错误。

specload 测试失败非常明确：

是的，但是在安装应用程序后期望构建目录中的二进制文件是错误的。 应在构建或安装目录中安装和搜索二进制文件。

specload 测试失败非常明确：

是的，但是在安装应用程序后期望构建目录中的二进制文件是错误的。 应在构建或安装目录中安装和搜索二进制文件。

哦，我错过了你安装了 Elektra。 但是，这并不能解释quickdump失败，它的测试数据安装正确。

我也不确定如何解决这个问题。 当然，我们可以安装测试应用程序的可执行文件，但实际的测试可执行文件必须在安装期间进行修改，以更改它们查找测试应用程序的位置。

搜索二进制文件（在构建或安装目录中）的工作量太大，我们也可以排除安装测试。

我们可以简单地使用相对路径并确保它在安装过程中保持不变，例如将两个二进制文件放在同一个目录中。

是的好主意。

一个更通用的解决方案是，如果我们在构建目录中也有kdb <command>可用（目前仅在安装 Elektra 时才有效）。 这将是相当多的工作，因为 KDB_EXEC_PATH 只支持一个路径，但二进制文件分散在构建目录的许多不同部分。

我们有 kdb在构建目录中也可用

可以通过ctest和/或make轻松执行测试。 至于其他命令，无论如何，它们中的大多数只对已安装的 Elektra 版本有意义。

我们可以简单地使用相对路径并确保它在安装过程中保持不变，例如将两个二进制文件放在同一个目录中。

事实证明，这比预期的要难。 stdlib 会将相对路径视为相对于当前工作目录，这没有帮助，并且无法以独立于平台的方式解析相对于当前可执行文件路径的路径。

因此， kdb <command>方式将非常有吸引力。

对于安装，将其安装到 TARGET_TOOL_EXEC_FOLDER 就足够了

只有在构建期间，我们需要某种方式来组合 build_dir/bin build_dir/scripts source_dir/scripts 和当前目录（也可能是 build+source）。

@kodebach这仍然开放吗？ 我们可以检测到这种情况并让测试不在这种情况下运行吗？

或者我们修复它：KDB_EXEC_PATH 现在允许多个路径，因此我们可以从 build/source 目录添加我们需要的任何文件夹。 然后，您只需让kdb完成查找可执行文件的工作。

AFAIK 这仍然是开放的，是的。

我们已经有了用于测试的函数srcdir_file 。 我们可以引入一个类似的bindir_file 。 bindir将默认为${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} ，但它们会以某种方式覆盖它。 将设置 CTest（通过 CMake 的add_test ），以便在使用ctest $ 时将 $ bindir设置为${CMAKE_BINARY_DIR}/bin #$ 。

并且简单地将绑定器添加到 KDB_EXEC_PATH 并使用kdb <bin>不起作用？

不，有几个原因：

1. 这些是testmod_测试，它们不应该依赖kdb 。
2. 那么我们如何找到kdb呢？ 使用make run_all执行测试不应使用已安装的kdb ，而应使用 $ ${CMAKE_BINARY_DIR}/bin中的那个。
3. 在安装kdb之后， KDB_EXEC_PATH仍会包含${CMAKE_BINARY_DIR}/bin文件夹，这可能会导致不同的问题。

这些是 testmod_ 测试，它们不应该依赖 kdb。

是的我同意。 如果它们独立工作，那就太好了。

那么我们如何找到kdb呢？ 使用 make run_all 执行测试不应使用已安装的 kdb，而应使用 ${CMAKE_BINARY_DIR}/bin 中的 kdb。

Shellrecorder 测试已经使用 kdb，它们适用于已安装的 Elektra 和构建目录（即使已安装 Elektra）。

在安装 kdb 之后，KDB_EXEC_PATH 仍将包含 ${CMAKE_BINARY_DIR}/bin 文件夹，这可能会导致不同的问题。

不，没有为已安装的 kdb 设置 KDB_EXEC_PATH（除非用户设置它）

Shellrecorder 测试已经使用 kdb，它们适用于已安装的 Elektra 和构建目录（即使已安装 Elektra）。

这是有效的，因为 shell 测试总是执行"$KDB"而从不执行kdb 。 并且还因为make run_all和ctest使用例如testscr_check_meta.sh脚本，而kdb使用例如check_meta.sh 。 在第一个中，我们将$KDB设置为${CMAKE_BINARY_DIR}/bin/kdb在第二个中，它只是设置为kdb （因此通过$PATH解决）。

不，没有为已安装的 kdb 设置 KDB_EXEC_PATH（除非用户设置它）

我刚拿了 Elektra 的主版本并安装了它。 文件/usr/local/lib/elektra/tool_exec/check_meta包含以下行：

export KDB_EXEC_PATH="/home/klemens/libelektra/build/bin:$KDB_EXEC_PATH"

当然这不会影响testmod_*测试，但它仍然是错误的。 我将创建一个新问题。

@petermax2 @kodebach这个问题的状态是什么？ 是因为#3246 现在已修复（通过#3409），这个问题的其余部分只是包装问题还是还有什么需要实现的？

AFAIK specload的原始问题仍然存在。 TBH 我不确定为什么我们甚至必须选择安装testmod_测试。 这个不成立。 这些是独立测试单个插件的独立测试。 如果它们实际运行，无论是在构建目录还是安装目录中执行，它们的结果都是一样的。

TBH 我不确定为什么我们甚至必须选择安装 testmod_ 测试。

目前我们没有禁用安装测试的选项，但我们可以进行本地覆盖以使add_plugintest不安装测试（如 INSTALL_TESTING 但针对个别add_plugintest ）。

这个不成立。 这些是独立测试单个插件的独立测试。 如果它们实际运行，无论是在构建目录还是安装目录中执行，它们的结果都是一样的。

:wink:, 有很多不同之处，但大多数都与插件系统本身有关（希望它们现在都已修复）。 但是，仍然存在大量可能的依赖问题和安装问题，因此在安装状态下运行 testmod 测试总比什么都不运行要好得多。 但是你是对的，如果有一个 shellrecorder 测试，那么 testmod 测试是没有用的。

• [X] 所以对于 quickdump 很明显，不需要安装 testmod 测试。
• [ ] 对于 specload 有一个测试，但它似乎很小，也许还可以，但最好再检查一次。
• [ ] 对于 gopts，我们可以让示例程序在 doc/tutorials/command-line-options.md 中运行吗？

@kodebach您能否检查这些测试是否可以安全排除？

@robaerd你能在你的 CI PR 中排除它们吗？ （在您添加包测试之前或位置。）

@markus2330 quickdump 问题仍然存在吗？ AFAIK 我们从来没有弄清楚那里出了什么问题。 我也无法重现它。

对于 gopts 和 specload，请参见 #3618

是的，仍然发生：

kdb testmod_quickdump                                                                                                                                                                                                                    
QUICKDUMP     TESTS
==================

test varint
test basics
/home/jenkins/workspace/libelektra_master/libelektra/src/plugins/quickdump/testmod_quickdump.c:111: error in test_basics: call to kdbSet was not successful
zsh: segmentation fault (core dumped)  noglob kdb testmod_quickdump

或者当我从源代码调用它时：

```快速转储测试

测试变量
测试基础
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:92：test_basics 中的错误：调用 kdbGet 不成功
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93：test_basics 中的错误：mmks2 的实际大小为 0
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93：test_basics 中的错误：比较键集失败，键集的大小不等于大小（mmks1）：8，大小（mmks2）： 0
mmks1：
0x55a9efd438d0 键：目录：/tests/bench/__112，字符串：gQHLlzB36CqIFlf，元：/元/_35：O6xNya6srhNhMFC，元：/元/_39：ublVuvyh1DgfOKU，元：/元/_58：5Nyde2MHJODCBAT，元：/元/_79： ZK2xlaRMfobquxp，元：/元/_90：0kCcc1pK7hOgY3F
0x55a9efd44250 键：目录：/tests/bench/__114，字符串：，元：/二进制：
0x55a9efd441a0 键：dir:/tests/bench/__333，字符串：SxTUAjM6OIpUV6s
0x55a9efd440f0 键：dir:/tests/bench/__506，字符串：cGqEvmXxUayNCf8
0x55a9efd44040 键：dir:/tests/bench/__859，字符串：rOI5aVFGlnjPLYJ
0x55a9efd43f90 键：dir:/tests/bench/__863，字符串：8IBjbd5pzYBehrs
0x55a9efd43f20 键：dir:/tests/bench/__868，字符串：UVM0OPTf68yNXij
0x55a9efd43d90 键：目录：/tests/bench/__911，字符串：PgNbwPxfeqD30pH，元：/meta/_35：O6xNya6srhNhMFC
mmks2：
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:111：test_basics 中的错误：调用 kdbSet 不成功
zsh：分段错误（核心转储）LD_LIBRARY_PATH=lib bin/testmod_quickdump

Stacktrace:

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) at getc.c:37

1 0x000055a9ede54c58 in compare_binary_files (filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump" )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics () 在 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 0x000055a9ede545d7 在 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278 中的 main (argc=1, argv=0x7ffff28085f8)

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) at getc.c:37

37 getc.c: Datei oder Verzeichnis nicht gefunden。
(gdb) BT

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) at getc.c:37

1 0x000055a9ede54c58 in compare_binary_files (filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump" )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics () 在 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 0x000055a9ede545d7 在 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278 中的 main (argc=1, argv=0x7ffff28085f8)

(gdb) bt 已满

0 0x00007fa7c770ed74 in _IO_getc (fp=0x0) at getc.c:37

    result = <optimized out>

1 0x000055a9ede54c58 in compare_binary_files (filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump" )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31
    f2 = 0x0
    c1 = <optimized out>
    f1 = 0x0
    result = 0
    c2 = <optimized out>
    f1 = <optimized out>
    f2 = <optimized out>
    result = <optimized out>
    c1 = <optimized out>
    c2 = <optimized out>
    end1 = <optimized out>
    end2 = <optimized out>

2 test_basics () 在 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

    conf = <optimized out>
    modules = 0x55a9efd43a00
    setKey = 0x55a9efd42bb0
    errorKey = <optimized out>
    plugin = 0x55a9efd43b00
    ks = <optimized out>
    infile = 0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump"
    outfile = 0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out"
    __func__ = "test_basics"

3 0x000055a9ede545d7 在 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:27 中的 main (argc=1, argv=0x7ffff28085f8)

```

或者当我从源代码调用它时：

直接运行测试时，请使用ctest （例如ctest -R testmod_quickdump --ouptut-on-failure ）来确保环境、参数等设置正确。

在这种情况下，我认为LD_LIBRARY_PATH=lib bin/testmod_quickdump ../src/plugins/quickdump是您需要的（如果您想使用例如gdb进行调试）。

您的系统上是否存在/usr/local/share/elektra/test_data/quickdump/test.quickdump并且该进程是否有权写入/usr/local/share/elektra/test_data/quickdump/test.quickdump.out ？ （也许你需要sudo kdb testmod_quickdump ）

如果有，请补充

output_error (setKey);
output_warnings (setKey);

在testmod_quickdump.c:112并发布输出。

elektraQuickdumpSet失败了，所以compare_binary_files失败是完全可以预料的。 （错误消息当然可以更好，并且可以避免段错误，但这是一个_failed_测试，所以它并不重要）

是的，问题在于测试用例尝试将临时文件创建到不适合的文件夹中。 sudo kdb testmod_quickdump运行没有问题。 所以使用我们的函数来创建临时文件就足够了，而不是使用“test_data/quickdump/test.quickdump.out”

是的，我们可以改变这一点，但是无论如何，如果没有sudo ，许多测试就无法运行，所以我真的不认为这是一个问题

你说的是哪些测试？ 我总是在没有 sudo 的情况下运行整个套件（但对 Elektra 的路径具有写入权限）。 testmod_quickdump 是唯一有这个问题的测试。

但对 Elektra 的路径有写权限

好吧，这也可以，但是在标准系统上，这些路径仅是 root 访问权限。

我仍然认为在已安装的 Elektra 版本中运行单元测试的整个概念很奇怪，并且 quickdump 问题纯粹是用户权限问题而不是错误，但我将在 #3618 中更改路径。

我现在更新了#3618 中的代码。 我还在testmod_dump中找到了类似的代码，并且更改得很好。 不知道，为什么这对你没有失败。 testmod_xmltool可能有类似的问题（虽然代码不同，所以我没有更改它）。

testmod_quickdump仅适用于使用二进制文件的文件之一，因此不使用compare_line_files 。 因此其他人不会出现段错误，但测试仍然应该失败。

nd quickdump 问题纯粹是用户权限问题而不是错误，

这违反了 FHS，应用程序不应该写入 /usr，它甚至可能是只读的。

对于写作，我们应该只使用临时文件，我们还应该在测试完成后清理它们。