ハドソン、C ++およびUnitTest ++
-
03-07-2019 - |
質問
どのように設定しましたか?
以前は継続的インテグレーションに関していくつかの質問があったことは知っていますが、この質問の範囲が狭いことを望みます。
編集:探しているものを少し明確にします。ユニットテストが失敗したときに失敗するように、ビルドセットを既に持っています。 HudsonのJUnitサポートのようなものを探しています。 UnitTest ++はXMLレポートを作成できます(こちらを参照)。それで、もし誰かがこれらのレポートをJUnit互換に変換する方法を知っていれば、ハドソンはそれを食い止める方法を知っているでしょうか?
解決
私は職場でこれを積極的に行っています。
現在、フリースタイルのソフトウェアプロジェクトを使用して、次のことを行っています。
- 15分ごとにSubversionリポジトリの更新を確認します
- Windowsバッチファイルを呼び出して、ソリューションファイルを削除およびビルドします
- プロジェクトファイルはビルド後のイベントとして単体テストをビルドおよび実行します
- 単体テストの失敗はテスト
main()
によって返されるため、ビルドエラーとして扱われます
UnitTest ++に含まれているXmlTestReporterを使用して出力ファイルを生成する構成もテストしました。 xUnitプラグインは、この出力と他の可能な出力をネイティブにサポートします。変換しますが、バージョン0.1.3に付属するXSLファイルを変更して、テスト履歴に期間を記録する必要がありました。
統合について改善したいことがたくさんあります。ビルドログは長く、解析や色付けや強調表示などは困難ですが、これまでのところ有益でした。
他のヒント
Patrick Johnmeyerが提案したように、 xUnit プラグインをチェックしました受け入れられた答え。完全を期すために、ここにドライバーコードを示します。
#include <fstream>
#include "UnitTest++.h"
#include "XmlTestReporter.h"
int main( int argc, char *argc[] ) {
std::ofstream f("file.xml");
UnitTest::XmlTestReporter reporter(f);
return UnitTest::RunAllTests(reporter, UnitTest::Test::GetTestList(), NULL, 0);
}
Hudsonの設定で、「テストツールの結果レポートを公開する」をチェックします。 &quot; file.xml&quot;
Hudsonには、 CppUnitプラグインがあります。 。
ハドソンの使用を開始するずっと前から、cpp-unit-liteとCruiseControlを使用するC ++プロジェクトに取り組みました
XMLレポートファイルのようなJUnitを生成するようにCpp-unit-liteを変更し、CruiseControlがXMLレポートファイルを取得しました。
UnitTest ++でも同じことができ、Hudsonはレポートファイルを取得します。
しかし、それは多くの作業のようです。 Hudsonのプロットプラグインをご覧ください。 UnitTest ++出力から失敗/合格テストの数をスクリプトで抽出し、プロットプラグインを使用して、ビルドごとに合格/失敗テストの簡単なグラフを描画できます。
組み込みの単体テストレポートほどではありませんが、すぐに作業できるものです。
CppUnitおよびxml出力でhudsonを使用します。 xmlはxsltによってJUnit出力に変換されます。 CppUnitサイトは、CppUnit出力をJUnit出力に変換するxsltを提供します。次のような詳細を取得するために、少しハッキングしました:
- パッケージとしての名前空間
- 実行時間
xml出力を変換して、次のものを取得できます。
<?xml version="1.0" encoding="UTF-8"?>
<testsuite>
<testcase name="my test name"
classname="Package1.Package2.TestClass"
time="0.25">
<error type="error"/>
</testcase>
....
</testsuite>
成功した場合:サブタグを削除するだけ
よろしく
UnitTest ++の代わりにcxxtestを使用することを除いて、私のオフィスで同様のアプローチを使用しており、現在Googleの非常に優れた(imho)gtestフレームワークに移行しています。
cxxtestを使用して、Patrick J.が提案したものと同様のことを行いました。基本的には、antを介してテストスイートプログラムを実行し、テストが失敗した場合にビルドを失敗させるビルドステップを追加することでしたこのアプローチの欠点は、テスト結果が原因でビルドが失敗した場合、コンソールの出力を調べて何が問題なのかを把握する必要があることです。また、テストフレームワークがjunit互換のXMLを出力できる場合、hudsonが生成できる気の利いたチャートを失います。
gtestに切り替える動機付け要因の1つは、junit XMLを生成することです。そのため、理論上、ハドソンはテスト結果を解析し、より適切な方法で公開できます。とにかく、UnitTest ++がこのようなものを生成するようには見えません(間違っている場合は私を修正してください)ので、それは議論の余地があるかもしれませんが、少なくともそれをビルドプロセスに統合すると、テストが実行されますビルド。