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エラーと一致します。

スペックロードテストの失敗は非常に明白です。

はい。ただし、アプリケーションのインストール後にビルドディレクトリにバイナリを期待するのは誤りです。 バイナリは、ビルドディレクトリまたはインストールディレクトリのいずれかにインストールして検索する必要があります。

スペックロードテストの失敗は非常に明白です。

はい。ただし、アプリケーションのインストール後にビルドディレクトリにバイナリを期待するのは誤りです。 バイナリは、ビルドディレクトリまたはインストールディレクトリのいずれかにインストールして検索する必要があります。

ああ、あなたがエレクトラをインストールしたのを見逃しました。 ただし、それはquickdumpの失敗を説明するものではなく、そのテストデータは正しくインストールされています。

また、この問題を解決する方法もわかりません。 もちろん、テストアプリの実行可能ファイルをインストールすることもできますが、実際のテスト実行可能ファイルは、インストール時にテストアプリを探す場所を変更するために変更する必要があります。

（ビルドまたはインストールされたディレクトリのいずれかで）バイナリを検索するのは大変な作業です。テストをインストールから除外することもできます。

相対パスを使用して、インストール中に同じパスを維持することもできます。たとえば、両方のバイナリを同じディレクトリに配置します。

はい、良い考えですね。

より一般的な解決策は、ビルドディレクトリでもkdb <command>使用できる場合です（現在、Elektraがインストールされている場合にのみ機能します）。 KDB_EXEC_PATHは1つのパスしかサポートしていませんが、バイナリはビルドディレクトリのさまざまな部分に散在しているため、かなりの作業になります。

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で複数のパスが許可されるようになったため、ビルド/ソースディレクトリから必要なフォルダを追加できます。 次に、 kdbに実行可能ファイルを見つける作業を任せます。

AFAIKこれはまだ開いています、はい。

テスト用の関数srcdir_fileはすでにあります。 同様のbindir_fileを導入することもできます。 bindirはデフォルトで${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER}になりますが、それをオーバーライドする方法があります。 CTestは、 ctestを使用するときにbindirが${CMAKE_BINARY_DIR}/binに設定されるように（CMakeのadd_testを介して）設定されます。

そして、単にbindirを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_EXEC_PATHはインストールされたkdbに設定されていません（ユーザーが設定しない限り）

Shellrecorderテストはすでにkdbを使用しており、インストールされているElektraとビルドディレクトリ（Elektraがインストールされている場合でも）の両方で機能します。

シェルテストは常に"$KDB"を実行し、$＃$ kdb $＃$を実行しないため、これは機能します。 また、 make run_allとctestはたとえばtestscr_check_meta.shスクリプトを使用し、 kdbはたとえばcheck_meta.shを使用するためです。 最初の例では$KDBを${CMAKE_BINARY_DIR}/bin/kdbに設定し、2番目の例では単にkdbに設定します（したがって、 $PATHを介して解決します）。

いいえ、KDB_EXEC_PATHはインストールされたkdbに設定されていません（ユーザーが設定しない限り）

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経由で）修正されていますが、この問題の残りの部分はパッケージングの問題のみですか、それとも実装する必要があるものが残っていますか？

specloadの元の問題はまだ存在しています。 TBH testmod_テストをインストールするオプションが必要な理由がわかりません。 意味がない。 これらは、単一のプラグインを個別にテストするスタンドアロンテストです。 実際に実行した場合、ビルドディレクトリまたはインストールディレクトリのどちらで実行しても、結果は同じになります。

TBHなぜtestmod_testsをインストールするオプションが必要なのかわかりません。

現時点では、テストのインストールを無効にするオプションはありませんが、ローカルオーバーライドを作成して、 add_plugintestがテストをインストールしないようにすることができます（INSTALL_TESTINGのように、個々のadd_plugintest ）。

意味がない。 これらは、単一のプラグインを個別にテストするスタンドアロンテストです。 実際に実行した場合、ビルドディレクトリまたはインストールディレクトリのどちらで実行しても、結果は同じになります。

：wink ：、たくさんの違いがありますが、それらのほとんどはプラグインシステム自体に関連していました（うまくいけば、今ではすべて修正されています）。 ただし、それでも、依存関係の問題やインストールの問題はさまざまに発生する可能性があるため、何も実行しないよりも、インストール済みの状態でtestmodテストを実行する方がはるかに優れています。 しかし、shellrecorderテストがある場合、testmodテストは役に立たないというのは正しいことです。

• [X]したがって、クイックダンプの場合は明らかですが、testmodテストをインストールする必要はありません。
• []スペックロードについてはテストがありますが、それは非常に最小限のようです。おそらく大丈夫ですが、もう一度確認することをお勧めします。
• [] goptsの場合、サンプルプログラムをdoc / tutorials / command-line-options.mdで実行させることができますか？

@kodebachこれらのテストを安全に除外できるかどうかを確認できますか？

@robaerd CI PRの1つでそれらを除外できますか？ （パッケージのテストを追加する前または追加する場所。）

@ markus2330クイックダンプの問題は引き続き発生しますか？ 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のエラー：キーセットの比較に失敗しました。キーセットのサイズがsize（mmks1）：8、size（mmks2）と等しくありません： 0
mmks1：
0x55a9efd438d0キー：dir：/ tests / branch / __ 112、文字列：gQHLlzB36CqIFlf、meta：/ meta / _35：O6xNya6srhNhMFC、meta：/ meta / _39：ublVuvyh1DgfOKU、meta：/ meta / _58：5Nyde2MH ZK2xlaRMfobquxp、meta：/ meta / _90：0kCcc1pK7hOgY3F
0x55a9efd44250キー：dir：/ tests / branch / __ 114、string：、meta：/ binary：
0x55a9efd441a0キー：dir：/ tests / branch / __ 333、文字列：SxTUAjM6OIpUV6s
0x55a9efd440f0キー：dir：/ tests / branch / __ 506、文字列：cGqEvmXxUayNCf8
0x55a9efd44040キー：dir：/ tests / branch / __ 859、string：rOI5aVFGlnjPLYJ
0x55a9efd43f90キー：dir：/ tests / branch / __ 863、string：8IBjbd5pzYBehrs
0x55a9efd43f20キー：dir：/ tests / branch / __ 868、文字列：UVM0OPTf68yNXij
0x55a9efd43d90キー：dir：/ tests / branch / __ 911、文字列：PgNbwPxfeqD30pH、meta：/ 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 ）。

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 in main（argc = 1、argv = 0x7ffff28085f8）at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278

0 0x00007fa7c770ed74 in _IO_getc（fp = 0x0）at getc.c：37

37 getc.c：Datei oder Verzeichnis nichtgefunden。
（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 ）。

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 in main（argc = 1、argv = 0x7ffff28085f8）at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278

（gdb）bt full

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 ）。

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 in main（argc = 1、argv = 0x7ffff28085f8）at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:27

`` `

または私がソースからそれを呼び出すとき：

テストを直接実行する場合は、 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が失敗するという事実は完全に予想されます。 （もちろん、エラーメッセージの方が優れていて、セグメンテーション違反を回避できますが、これは_失敗した_テストであるため、それほど重要ではありません）

はい、問題は、テストケースがそれに適さないフォルダに一時ファイルを作成しようとすることです。 sudo kdb testmod_quickdumpは問題なく実行されます。 したがって、「test_data / quickdump / test.quickdump.out」を使用する代わりに、関数を使用して一時ファイルを作成するだけで十分です。

はい、変更できますが、とにかく多くのテストはsudoなしでは実行されないため、これを問題とは見なしません。

どのテストについて話しているのですか？ 私は常にsudoなしでスイート全体を実行します（ただし、Elektraのパスへの書き込み権限はあります）。 testmod_quickdumpは、その問題を抱える唯一のテストです。

ただし、Elektraのパスへの書き込み権限があります

それも機能しますが、標準システムでは、これらのパスはルートアクセスのみです。

インストールされたバージョンのElektraで単体テストを実行するという概念全体は奇妙だと思います。クイックダンプの問題は純粋にユーザー権利の問題であり、バグではありませんが、＃3618でパスを変更します。

＃3618のコードを更新しました。 testmod_dumpでも同様のコードを見つけて、それを変更しました。 わからない、なぜそれがあなたのために失敗しなかったのか。 testmod_xmltoolでも同様の問題が発生する可能性があります（ただし、コードが異なるため、変更しませんでした）。

testmod_quickdumpは、バイナリファイルを使用したため、 compare_line_filesを使用しなかったものの1つにのみ適用されました。 したがって、他のユーザーはセグメンテーション違反になりませんが、テストは失敗するはずです。

クイックダンプの問題は純粋にユーザー権利の問題であり、バグではありません。

これはFHSの違反であり、アプリケーションは/ usrに書き込むことは想定されておらず、読み取り専用である可能性もあります。

書き込みには、一時ファイルのみを使用する必要があり、テストの終了後にそれらをクリーンアップする必要もあります。