El error de la prueba specload es bastante explícito:

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

Para quickdump no puedo decir exactamente qué está mal, pero falla en algún lugar en elektraQuickdumpSet . Debería haber un error establecido en setKey , pero creo que no está registrado (eso probablemente debería cambiarse).

Ni idea, por qué gopts falla. Dado que no se imprimió ningún mensaje de error, sospecho que la aplicación de prueba elektra-gopts-testapp no se pudo ejecutar (es el único caso en el que no se imprime ningún mensaje de error). También estaría en línea con el error specload .

La falla de la prueba de carga de especificaciones es bastante explícita:

Sí, pero es incorrecto esperar archivos binarios en el directorio de compilación después de instalar la aplicación. Los binarios deben instalarse y buscarse en el directorio de compilación o instalación.

La falla de la prueba de carga de especificaciones es bastante explícita:

Sí, pero es incorrecto esperar archivos binarios en el directorio de compilación después de instalar la aplicación. Los binarios deben instalarse y buscarse en el directorio de compilación o instalación.

Oh, me perdí que instalaras Elektra. Sin embargo, eso no explica la falla quickdump , sus datos de prueba están instalados correctamente.

Tampoco estoy seguro de cómo resolver este problema. Por supuesto, podemos instalar los ejecutables de las aplicaciones de prueba, pero los ejecutables de prueba reales tendrían que modificarse durante el tiempo de instalación para cambiar dónde buscan la aplicación de prueba.

Es demasiado trabajo buscar los archivos binarios (ya sea en el directorio de compilación o instalado), también podemos excluir las pruebas de la instalación.

Podríamos simplemente usar una ruta relativa y asegurarnos de que permanezca igual durante la instalación, por ejemplo, tener ambos archivos binarios en el mismo directorio.

Sí, buena idea.

Una solución más general sería si tuviéramos kdb <command> disponibles también en el directorio de compilación (actualmente solo funciona si Elektra está instalado). Sería bastante trabajo ya que KDB_EXEC_PATH solo admite una ruta, pero los archivos binarios están dispersos en muchas partes diferentes del directorio de compilación.

tenemos kdbdisponible también en el directorio de compilación

Las pruebas se pueden ejecutar fácilmente a través ctest y/o make . En cuanto a los otros comandos, la mayoría de ellos solo tienen sentido para una versión instalada de Elektra de todos modos.

Podríamos simplemente usar una ruta relativa y asegurarnos de que permanezca igual durante la instalación, por ejemplo, tener ambos archivos binarios en el mismo directorio.

Resulta que esto es más difícil de lo esperado. stdlib trataría la ruta relativa como relativa al directorio de trabajo actual, lo que no es útil y resolver la ruta relativa a la ruta del ejecutable actual no es posible de una manera independiente de la plataforma.

Por lo tanto, la forma kdb <command> sería bastante atractiva.

Para la instalación es suficiente instalarlo en TARGET_TOOL_EXEC_FOLDER

Solo durante el tiempo de compilación necesitamos alguna forma de combinar build_dir/bin build_dir/scripts source_dir/scripts y los directorios actuales (quizás también ambos build+source).

@kodebach sigue abierto? ¿Podemos muchos detectar esta situación y dejar que las pruebas no se ejecuten en esta situación?

O lo arreglamos: KDB_EXEC_PATH ahora permite múltiples rutas, por lo que podemos agregar las carpetas que necesitemos desde el directorio de compilación/fuente. Luego, simplemente deje que kdb haga el trabajo de encontrar el ejecutable.

AFAIK esto todavía está abierto, sí.

Ya tenemos la función srcdir_file para pruebas. Podríamos introducir un bindir_file similar. bindir por defecto sería ${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} , pero habría alguna forma de anularlo. CTest se configuraría (a través de add_test de CMake) de modo que bindir se establezca en ${CMAKE_BINARY_DIR}/bin cuando se use ctest .

¿Y simplemente agregar el bindir a KDB_EXEC_PATH y usar kdb <bin> no funciona?

No, por algunas razones:

1. Estas son pruebas testmod_ , no deben depender de kdb .
2. ¿Cómo encontraríamos kdb entonces? Ejecutar pruebas con make run_all no debería usar el kdb instalado, sino el que está en ${CMAKE_BINARY_DIR}/bin .
3. KDB_EXEC_PATH todavía contendría la carpeta ${CMAKE_BINARY_DIR}/bin , después de instalar kdb , lo que podría causar diferentes problemas.

Estas son pruebas testmod_, no deberían depender de kdb.

Sí estoy de acuerdo. Es bueno si funcionan de forma independiente.

¿Cómo encontraríamos kdb entonces? La ejecución de pruebas con make run_all no debe usar el kdb instalado, sino el que está en ${CMAKE_BINARY_DIR}/bin.

Las pruebas de Shellrecorder ya usan kdb, y funcionan tanto para Elektra instalado como desde el directorio de compilación (incluso si Elektra está instalado).

KDB_EXEC_PATH todavía contendría la carpeta ${CMAKE_BINARY_DIR}/bin, después de instalar kdb, lo que podría causar diferentes problemas.

No, KDB_EXEC_PATH no está configurado para un kdb instalado (a menos que el usuario lo configure)

Las pruebas de Shellrecorder ya usan kdb, y funcionan tanto para Elektra instalado como desde el directorio de compilación (incluso si Elektra está instalado).

Eso funciona porque las pruebas de shell siempre ejecutan "$KDB" y nunca kdb . Y también porque make run_all y ctest usan, por ejemplo testscr_check_meta.sh scripts, mientras que kdb usa, por ejemplo check_meta.sh . En el primero establecemos $KDB a ${CMAKE_BINARY_DIR}/bin/kdb en el segundo, simplemente se establece en kdb (y por lo tanto se resuelve a través $PATH ).

No, KDB_EXEC_PATH no está configurado para un kdb instalado (a menos que el usuario lo configure)

Acabo de tomar la versión maestra de Elektra y la instalé. El archivo /usr/local/lib/elektra/tool_exec/check_meta contiene la línea:

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

Por supuesto, esto no afecta las pruebas testmod_* , pero no obstante es incorrecto. Voy a crear un nuevo problema.

@petermax2 @kodebach ¿cuál es el estado de este problema? ¿Se corrigió el #3246 ahora (a través del #3409), el resto de este problema solo son problemas de empaquetado o queda algo por implementar?

AFAIK, el problema original con specload todavía existe. TBH No estoy seguro de por qué tenemos la opción de instalar pruebas testmod_ . No tiene sentido. Estas son pruebas independientes que prueban un solo complemento de forma aislada. Si realmente se ejecutan, sus resultados serán los mismos sin importar si se ejecutan en el directorio de compilación o en el directorio de instalación.

TBH No estoy seguro de por qué tenemos la opción de instalar testmod_ tests.

Por el momento no tenemos una opción para deshabilitar la instalación de pruebas, pero podríamos hacer una anulación local para hacer que add_plugintest no instale pruebas (como INSTALL_TESTING pero para add_plugintest individuales).

No tiene sentido. Estas son pruebas independientes que prueban un solo complemento de forma aislada. Si realmente se ejecutan, sus resultados serán los mismos sin importar si se ejecutan en el directorio de compilación o en el directorio de instalación.

:wink:, hay muchas diferencias, pero la mayoría de ellas estaban relacionadas con el propio sistema de complementos (esperemos que ya estén solucionadas). Pero aún así, existe una amplia gama de posibles problemas de dependencia y problemas de instalación, por lo que ejecutar las pruebas de testmod en el estado instalado es mucho mejor que no ejecutar nada. Pero tiene razón en que si hay una prueba de shellrecorder, la prueba de testmod es inútil.

• [X] Entonces, para quickdump está claro, no es necesario instalar la prueba testmod.
• [ ] Para la carga de especificaciones hay una prueba, pero parece bastante mínima, tal vez esté bien, pero es mejor que verifique nuevamente.
• [ ] Para los gopts, ¿podríamos permitir que se ejecuten programas de ejemplo en doc/tutorials/command-line-options.md?

@kodebach , ¿puede verificar si estas pruebas se pueden excluir de manera segura?

@robaerd , ¿puede excluirlos en uno de sus PR de CI? (Antes o donde agrega pruebas de paquetes).

@markus2330 ¿Sigue ocurriendo el problema de volcado rápido? AFAIK, nunca descubrimos qué estaba mal allí. Tampoco pude reproducirlo.

Para gopts y specload ver #3618

Sí, todavía ocurre:

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

O cuando lo llamo desde la fuente:

```PRUEBAS DE DESCARGA RÁPIDA

variante de prueba
fundamentos de la prueba
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:92: error en test_basics: la llamada a kdbGet no tuvo éxito
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: error en test_basics: el tamaño real de mmks2 era 0
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: error en test_basics: error en la comparación del conjunto de claves, el tamaño de los conjuntos de claves no es igual al tamaño (mmks1): 8, tamaño (mmks2): 0
mmks1:
0x55a9efd438d0 clave: dir:/tests/bench/__112, cadena: gQHLlzB36CqIFlf, meta:/meta/_35: O6xNya6srhNhMFC, meta:/meta/_39: ublVuvyh1DgfOKU, meta:/meta/_58: 5Nyde2MHJODCBAT, meta:/meta/_79: ZK2xlaRMfobquxp, meta:/meta/_90: 0kCcc1pK7hOgY3F
0x55a9efd44250 clave: dir:/pruebas/banco/__114, cadena:, meta:/binario:
0x55a9efd441a0 clave: dir:/pruebas/banco/__333, cadena: SxTUAjM6OIpUV6s
0x55a9efd440f0 clave: dir:/pruebas/banco/__506, cadena: cGqEvmXxUayNCf8
0x55a9efd44040 clave: dir:/pruebas/banco/__859, cadena: rOI5aVFGlnjPLYJ
0x55a9efd43f90 clave: dir:/pruebas/banco/__863, cadena: 8IBjbd5pzYBehrs
0x55a9efd43f20 clave: dir:/pruebas/banco/__868, cadena: UVM0OPTf68yNXij
0x55a9efd43d90 clave: dir:/pruebas/banco/__911, cadena: PgNbwPxfeqD30pH, meta:/meta/_35: O6xNya6srhNhMFC
mmks2:
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:111: error en test_basics: la llamada a kdbSet no tuvo éxito
zsh: falla de segmentación (núcleo volcado) LD_LIBRARY_PATH=lib bin/testmod_quickdump

Stacktrace:

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

1 0x000055a9ede54c58 en 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 () en /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

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

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

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

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

1 0x000055a9ede54c58 en 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 () en /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

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

(gdb) bt completo

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

    result = <optimized out>

1 0x000055a9ede54c58 en 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 () en /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 en principal (argc=1, argv=0x7ffff28085f8) en /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:27

```

O cuando lo llamo desde la fuente:

Cuando ejecute pruebas directamente, use ctest (por ejemplo ctest -R testmod_quickdump --ouptut-on-failure ) para asegurarse de que el entorno, los argumentos, etc. estén configurados correctamente.

En este caso, creo que LD_LIBRARY_PATH=lib bin/testmod_quickdump ../src/plugins/quickdump es lo que necesita (si desea depurar con, por ejemplo gdb ).

¿Existe /usr/local/share/elektra/test_data/quickdump/test.quickdump en su sistema y el proceso tiene los derechos para escribir en /usr/local/share/elektra/test_data/quickdump/test.quickdump.out ? (Tal vez necesites sudo kdb testmod_quickdump )

Si es así, por favor agregue

output_error (setKey);
output_warnings (setKey);

en testmod_quickdump.c:112 y publique la salida.

elektraQuickdumpSet falló, por lo que el hecho de que compare_binary_files falle es completamente esperado. (El mensaje de error, por supuesto, podría ser mejor y la falla de segmento podría evitarse, pero es una prueba _fallida_, por lo que realmente no importa tanto)

Sí, el problema es que los casos de prueba intentan crear archivos temporales en una carpeta que no es adecuada para eso. sudo kdb testmod_quickdump se ejecuta sin problemas. Entonces debería ser suficiente usar nuestras funciones para crear archivos temporales en lugar de usar "test_data/quickdump/test.quickdump.out"

Podemos cambiar eso, sí, pero muchas pruebas no se ejecutan sin sudo todos modos, así que realmente no veo esto como un problema.

¿De qué pruebas estás hablando? Siempre ejecuto toda la suite sin sudo (pero con permisos de escritura en la ruta de Elektra). testmod_quickdump es afaik la única prueba con ese problema.

pero con permisos de escritura a la ruta de Elektra

Está bien, eso también funciona, pero en un sistema estándar esas rutas son solo acceso de root.

Sigo pensando que todo el concepto de ejecutar pruebas unitarias en una versión instalada de Elektra es extraño y el problema de volcado rápido es simplemente un problema de derechos de usuario, no un error, pero cambiaré la ruta en #3618.

Ahora he actualizado el código en #3618. También encontré un código similar en testmod_dump y lo cambié bien. Ni idea, por qué eso no te falló. testmod_xmltool podría tener un problema similar (aunque el código es diferente, así que no lo cambié).

testmod_quickdump era solo para uno de los que usaban archivos binarios y, por lo tanto, no usaba compare_line_files . Por lo tanto, los demás no fallarían, pero las pruebas aún deberían fallar.

y el problema de volcado rápido es puramente un problema de derechos de usuario, no un error,

Es una violación de FHS, se supone que las aplicaciones no deben escribir en /usr, incluso podría ser de solo lectura.

Para escribir, solo debemos usar archivos temporales y también debemos limpiarlos después de que finalicen las pruebas.