A falha do teste specload é bastante explícita:

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 não posso dizer exatamente o que está errado, mas falha em algum lugar em elektraQuickdumpSet . Deve haver um erro definido em setKey , mas acho que não está registrado (isso provavelmente deve ser alterado).

Não faço ideia, por que gopts falha. Como nenhuma mensagem de erro foi impressa, suspeito que o testapp elektra-gopts-testapp não pôde ser executado (é o único caso em que nenhuma mensagem de erro seria impressa). Também estaria de acordo com o erro specload .

A falha do teste specload é bastante explícita:

Sim, mas é errado esperar binários no diretório de compilação após a instalação do aplicativo. Os binários devem ser instalados e pesquisados ​​no diretório de compilação ou instalação.

A falha do teste specload é bastante explícita:

Sim, mas é errado esperar binários no diretório de compilação após a instalação do aplicativo. Os binários devem ser instalados e pesquisados ​​no diretório de compilação ou instalação.

Oh, eu perdi que você instalou o Elektra. No entanto, isso não explica a falha quickdump , seus dados de teste estão instalados corretamente.

Também não tenho certeza de como resolver esse problema. É claro que podemos instalar os executáveis ​​dos aplicativos de teste, mas os executáveis ​​de teste reais teriam que ser modificados durante o tempo de instalação para alterar onde eles procuram o aplicativo de teste.

É muito trabalhoso procurar os binários (no diretório de compilação ou instalado), também podemos excluir os testes de serem instalados.

Poderíamos simplesmente usar um caminho relativo e garantir que ele permaneça o mesmo durante a instalação, por exemplo, ter os dois binários no mesmo diretório.

Sim, boa ideia.

Uma solução mais geral seria se tivéssemos kdb <command> disponível também no diretório de compilação (atualmente só funciona se o Elektra estiver instalado). Seria bastante trabalhoso, pois KDB_EXEC_PATH suporta apenas um caminho, mas os binários estão espalhados em muitas partes diferentes do diretório de compilação.

nós temos kdbdisponível também no diretório de compilação

Testes podem ser facilmente executados via ctest e/ou make . Quanto aos outros comandos, a maioria deles só faz sentido para uma versão instalada do Elektra.

Poderíamos simplesmente usar um caminho relativo e garantir que ele permaneça o mesmo durante a instalação, por exemplo, ter os dois binários no mesmo diretório.

Acontece que isso é mais difícil do que o esperado. O stdlib trataria o caminho relativo como relativo ao diretório de trabalho atual, o que não é útil e resolver o caminho relativo ao caminho do executável atual não é possível de maneira independente da plataforma.

Assim, o caminho kdb <command> seria bastante atraente.

Para a instalação basta instalá-lo em TARGET_TOOL_EXEC_FOLDER

Somente durante o tempo de compilação precisamos de alguma forma de combinar build_dir/bin build_dir/scripts source_dir/scripts e os diretórios atuais (talvez também ambos build+source).

@kodebach isso ainda está aberto? Podemos muitos detectar essa situação e deixar os testes não serem executados nessa situação?

Ou corrigimos: KDB_EXEC_PATH agora permite vários caminhos, então podemos adicionar quaisquer pastas que precisarmos do diretório build/source. Então você simplesmente deixa kdb fazer o trabalho de encontrar o executável.

AFAIK isso ainda está aberto, sim.

Já temos a função srcdir_file para testes. Poderíamos introduzir um bindir_file semelhante. bindir por padrão seria ${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} , mas haveria alguma maneira de substituí-lo. CTest seria configurado (via add_test do CMake) de forma que bindir fosse definido como ${CMAKE_BINARY_DIR}/bin ao usar ctest .

E simplesmente adicionar o bindir ao KDB_EXEC_PATH e usar kdb <bin> não funciona?

Não, por alguns motivos:

1. Estes são testes testmod_ , eles não devem depender de kdb .
2. Como encontraríamos kdb então? A execução de testes com make run_all não deve usar o kdb instalado, mas sim o ${CMAKE_BINARY_DIR}/bin .
3. KDB_EXEC_PATH ainda conteria a pasta ${CMAKE_BINARY_DIR}/bin , após a instalação kdb , o que poderia causar diversos problemas.

Estes são testes testmod_, eles não devem depender do kdb.

Sim eu concordo. É bom que eles funcionem sozinhos.

Como encontraríamos o kdb então? A execução de testes com make run_all não deve usar o kdb instalado, mas sim o de ${CMAKE_BINARY_DIR}/bin.

Os testes do Shellrecorder já usam o kdb e funcionam tanto para o Elektra instalado quanto para o diretório de compilação (mesmo se o Elektra estiver instalado).

KDB_EXEC_PATH ainda conteria a pasta ${CMAKE_BINARY_DIR}/bin, após a instalação do kdb, o que poderia causar diversos problemas.

Não, KDB_EXEC_PATH não está definido para um kdb instalado (a menos que o usuário o defina)

Os testes do Shellrecorder já usam o kdb e funcionam tanto para o Elektra instalado quanto para o diretório de compilação (mesmo se o Elektra estiver instalado).

Isso funciona porque os testes de shell sempre executam "$KDB" e nunca kdb . E também porque make run_all e ctest usam, por exemplo testscr_check_meta.sh scripts, enquanto kdb usa, por exemplo check_meta.sh . No primeiro nós definimos $KDB para ${CMAKE_BINARY_DIR}/bin/kdb no segundo, ele é simplesmente definido como kdb (e, portanto, resolvido via $PATH ).

Não, KDB_EXEC_PATH não está definido para um kdb instalado (a menos que o usuário o defina)

Acabei de pegar a versão master do Elektra e instalei. O arquivo /usr/local/lib/elektra/tool_exec/check_meta contém a linha:

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

Claro que isso não afeta os testes testmod_* , mas está errado mesmo assim. Vou criar um novo problema.

@petermax2 @kodebach qual é o status deste problema? Como o #3246 está corrigido agora (via #3409), o resto deste problema apenas problemas de empacotamento ou há algo a ser implementado?

AFAIK o problema original com specload ainda existe. TBH Eu não sei por que ainda temos a opção de instalar testes testmod_ . Isso não faz sentido. Estes são testes independentes que testam um único plugin isoladamente. Se eles realmente forem executados, seus resultados serão os mesmos, não importa se executados no diretório de compilação ou no diretório de instalação.

TBH Eu não sei por que ainda temos a opção de instalar testmod_tests.

No momento, não temos a opção de desabilitar a instalação de testes, mas podemos fazer uma substituição local para fazer add_plugintest não instalar testes (como INSTALL_TESTING, mas para add_plugintest ).

Isso não faz sentido. Estes são testes independentes que testam um único plugin isoladamente. Se eles realmente forem executados, seus resultados serão os mesmos, não importa se executados no diretório de compilação ou no diretório de instalação.

:wink:, existem muitas diferenças, mas a maioria delas estava relacionada ao próprio sistema de plugins (esperamos que todas tenham sido corrigidas agora). Mas ainda assim, há uma grande variedade de possíveis problemas de dependência e problemas de instalação, portanto, executar os testes testmod no estado instalado é muito melhor do que não executar nada. Mas você está certo de que, se houver um teste de gravador de shell, o teste testmod é inútil.

• [X] Então para quickdump é claro, o teste testmod não precisa ser instalado.
• [ ] Para specload existe um teste, mas parece bem mínimo, talvez ok, mas é melhor você verificar novamente.
• [ ] Para gopts, podemos permitir que programas de exemplo sejam executados em doc/tutorials/command-line-options.md?

@kodebach você pode verificar se esses testes podem ser excluídos com segurança?

@robaerd você pode excluí-los em um dos seus PRs de CI? (Antes ou onde você adiciona testes de pacotes.)

@ markus2330 O problema do quickdump ainda ocorre para você? AFAIK nós nunca descobrimos o que estava errado lá. Também não consegui reproduzir.

Para gopts e specload veja #3618

Sim, ainda ocorre:

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

Ou quando eu chamo da fonte:

```TESTE RÁPIDO

variante de teste
teste básico
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:92: erro em test_basics: chamada para kdbGet não foi bem-sucedida
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: erro em test_basics: tamanho real de mmks2 era 0
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: erro em test_basics: Falha ao comparar o conjunto de chaves, o tamanho dos conjuntos de chaves não é igual ao tamanho (mmks1): 8, tamanho (mmks2): 0
mmks1:
0x55a9efd438d0 chave: dir:/tests/bench/__112, string: gQHLlzB36CqIFlf, meta:/meta/_35: O6xNya6srhNhMFC, meta:/meta/_39: ublVuvyh1DgfOKU, meta:/meta/_58: 5Nyde2MHJODCBAT, meta:/meta/_79: ZK2xlaRMfobquxp, meta:/meta/_90: 0kCcc1pK7hOgY3F
0x55a9efd44250 chave: dir:/tests/bench/__114, string: , meta:/binary:
0x55a9efd441a0 chave: dir:/tests/bench/__333, string: SxTUAjM6OIpUV6s
0x55a9efd440f0 chave: dir:/tests/bench/__506, string: cGqEvmXxUayNCf8
0x55a9efd44040 chave: dir:/tests/bench/__859, string: rOI5aVFGlnjPLYJ
0x55a9efd43f90 chave: dir:/tests/bench/__863, string: 8IBjbd5pzYBehrs
0x55a9efd43f20 chave: dir:/tests/bench/__868, string: UVM0OPTf68yNXij
0x55a9efd43d90 chave: dir:/tests/bench/__911, string: PgNbwPxfeqD30pH, meta:/meta/_35: O6xNya6srhNhMFC
mmks2:
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:111: erro em test_basics: chamada para kdbSet não foi bem-sucedida
zsh: falha de segmentação (núcleo despejado) LD_LIBRARY_PATH=lib bin/testmod_quickdump

Stacktrace:

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

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

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

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

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

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

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

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

(gdb) bt completo

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

    result = <optimized out>

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

```

Ou quando eu chamo da fonte:

Ao executar testes diretamente, use ctest (por exemplo ctest -R testmod_quickdump --ouptut-on-failure ) para garantir que o ambiente, os argumentos, etc. estejam configurados corretamente.

Nesse caso, acho que LD_LIBRARY_PATH=lib bin/testmod_quickdump ../src/plugins/quickdump é o que você precisa (se quiser depurar com, por exemplo gdb ).

Existe /usr/local/share/elektra/test_data/quickdump/test.quickdump em seu sistema e o processo tem o direito de gravar em /usr/local/share/elektra/test_data/quickdump/test.quickdump.out ? (Talvez você precise sudo kdb testmod_quickdump )

Se sim, por favor, adicione

output_error (setKey);
output_warnings (setKey);

em testmod_quickdump.c:112 e poste a saída.

elektraQuickdumpSet falhou, então o fato de compare_binary_files falhar é completamente esperado. (É claro que a mensagem de erro poderia ser melhor e o segfault poderia ser evitado, mas é um teste _failed_, então não importa muito)

Sim, o problema é que os casos de teste tentam criar arquivos temporários em uma pasta não adequada para isso. sudo kdb testmod_quickdump roda sem problemas. Portanto, deve ser suficiente usar nossas funções para criar arquivos temporários em vez de usar "test_data/quickdump/test.quickdump.out"

Podemos mudar isso sim, mas muitos testes não são executados sem sudo de qualquer maneira, então eu realmente não vejo isso como um problema

De quais testes você está falando? Eu sempre executo toda a suíte sem sudo (mas com permissões de gravação para o caminho da Elektra). testmod_quickdump é afaik o único teste com esse problema.

mas com permissões de gravação para o caminho da Elektra

Tudo bem, isso também funciona, mas em um sistema padrão esses caminhos são apenas de acesso root.

Ainda acho que todo o conceito de executar testes de unidade em uma versão instalada do Elektra é estranho e o problema do quickdump é puramente um problema de direitos do usuário, não um bug, mas vou mudar o caminho em #3618.

Agora atualizei o código em #3618. Eu também encontrei um código semelhante em testmod_dump e mudei isso bem. Não faço ideia, por que isso não falhou para você. testmod_xmltool pode ter um problema semelhante (embora o código seja diferente, então não o alterei).

testmod_quickdump era apenas um dos que usava arquivos binários e, portanto, não usava compare_line_files . Portanto, os outros não falhariam, mas os testes ainda deveriam falhar.

e o problema do quickdump é puramente um problema de direitos do usuário, não um bug,

É uma violação do FHS, os aplicativos não devem gravar em /usr, pode até ser somente leitura.

Para escrever, devemos usar apenas arquivos temporários e também devemos limpá-los após o término dos testes.