googletest でテストに失敗しても ビルド結果が失敗にならない

[m-tmatma]

バグ内容

googletest でテストに失敗しても ビルド結果が失敗にならない

再現手順

appveyor で任意のテストに失敗させる。

再現頻度

100%

環境情報

m-tmatma@35ef26d
https://ci.appveyor.com/project/m-tmatma/sakura/builds/22107286/tests

Test.Fail に失敗しているのに結果が失敗にならない。

もともと以下で発生
#776 (comment) ( https://ci.appveyor.com/project/sakuraeditor/sakura/builds/22084197/job/uv3v6g2m6sdqvyq8/tests )

[m-tmatma]

原因

sakura/tests/run-tests.bat

Lines 20 to 21 in f41567f

	@echo %%i | "%FILTER_BAT%"
	%%i | "%FILTER_BAT%" || set ERROR_RESULT=1

でテスト用の exe をフィルタ経由で実行しているので、テスト用の exe が終了コードで
0 以外を返しても、フィルタの終了コードが appveyor に返るので、失敗とみなされない。

試しに #735 を適用すると正しくエラーを認識できる。
https://ci.appveyor.com/project/m-tmatma/sakura/builds/22107380/tests

[berryzplus]

やっぱりソコですよね。

%FILTER_BAT% になんかしらの対応が要りそうです。
各行処理の前にerrorlevel判定を入れて終了コードを引き継げばいいんではないかと。

#735 の復活適用でもいいと思います・・・が、xml方式にはテスト結果がタブに反映されない課題があったはずで「curlを使う」という案が出たものの未検証だと思ってます。まぁ、なんかしら追加の作業が入りますね。

[ds14050]

パイプを通すと最後のコマンドの終了コードしか取れないというのは、検索するとよくある悩みのようでした(が、知りませんでした)。シェルによっては個別の終了コードを調べられるようにしているようですが、cmd.exe は違います。

---

test_result_filter_tell_AppVeyor.bat への作業はこんな感じになります。>master...ds14050:failingtest

インデントの深さが変わるせいで差分が無駄に大きくなっていますが、step 1,3,4 が本質的な変更です。

失敗したテストがあれば終了コード１を、パスしたテスト数の報告がなければ終了コード１を、それ以外の場合は終了コード０を返します。

[m-tmatma]

マージは#782 の後にする必要がある。
ただPR の作成は #782 の マージ前にする必要がある。

[ds14050]

フィルタバッチの修正を PR にしました> #784

個人用 AppVeyor でのビルド結果です>https://ci.appveyor.com/project/ds14050/sakura-clone/builds/22113399 MinGW/Debug のジョブに限って赤色で失敗とラベルされ、全体も失敗と判断されています。

[m-tmatma]

とりあえず #784 でやりたいことができているみたいなので
#784 (comment)
が通れば、それでいいと思います。

ただ、フィルタを使うという仕組み上、googletest が意図せず落ちた場合とかに
正しく失敗を認識できないんじゃないかと思います。

フィルタではなく、ランチャー (外部プロセスを起動して標準出力を処理する) 方式だと
確実に終了コードをとれると思います。

python の場合 subprocess を使う
https://maku77.github.io/python/env/call-external-program.html

powershell の場合、…… ものすごく複雑。調べるの断念。

[ds14050]

ただ、フィルタを使うという仕組み上、googletest が意図せず落ちた場合とかに正しく失敗を認識できないんじゃないかと思います。

テストプログラムが起動できない場合の処理は run-tests.bat の仕事になると思います。

テストプログラムが中断した場合は「パスしたテスト数の報告」がなされないので、フィルタにより失敗と判断されます。報告後の異常終了は拾えませんが。

ランチャーによる解法は run-tests.bat の置き換えになると思われるので別のお仕事です。シェルがやるパイプの処理を自前でやるわけですよね。フィルタのためにそこまでする価値はないんじゃないかなあ。今のやり方も今回の件でひとつ完成度が高まりました。

[ds14050]

issue 作成と原因の究明でお世話になりました。ありがとうございます> @m-tmatma さん

今後における「手段」の改善は大いに歓迎します。自ら取り組み考えた「問題・課題」に対する異なる方向からのアプローチは、よく身に付く貴重な学びの機会です(と、以前もどこかに書きました)。しかし課題の矮小化は困ります。

---

わからなかったのでスルーしてしまいました。

%FILTER_BAT% になんかしらの対応が要りそうです。
各行処理の前にerrorlevel判定を入れて終了コードを引き継げばいいんではないかと。

フィルタが起動するのは appveyor.exe なのでその終了コードを調べても意味がありません。それはさておいても、パイプの直前に位置するコマンドの終了コードを調べたり継承したりする方法はないみたいでした。できればそうしたかったのですが。

[ds14050]

GoogleTestAdapter という Visual Studio のエクステンションがある。

GoogleTestAdapter/GoogleTestAdapter/Core/TestResults at master · csoltenborn/GoogleTestAdapter

これを AppVeyor にインストールすることも一度は考えたが、標準出力のフォーマットが変わったときに自前で対応できない(アップデートを待たなければいけない)のが嫌だった。

[berryzplus]

%FILTER_BAT% になんかしらの対応が要りそうです。
各行処理の前にerrorlevel判定を入れて終了コードを引き継げばいいんではないかと。

フィルタが起動するのは appveyor.exe なのでその終了コードを調べても意味がありません。それはさておいても、パイプの直前に位置するコマンドの終了コードを調べたり継承したりする方法はないみたいでした。できればそうしたかったのですが。

「普通にやったら終了コードを取得できない」という事実を知らずに書いたので忘れてください 😭

tests1.exe が終了した直後に実行されるのはここの echo だろう、と思って書いたコメントでした。

https://github.com/ds14050/sakura-clone/blob/e33bc7e1de080328ccd2ecb83c5ce6fd4797fc4e/tests/test_result_filter_tell_AppVeyor.bat#L25-L28

FINDSTRはfor文の処理が終わるまでstdoutを開放できないから「終了しないはず(≒最後に終了したのは tests1.exe なはず)」と思ったんですが、パイプされた受け側で呼出元の終了コードを取るのは無理なんですね。残念。