Frage

Hat jemand verwendet Hudson als Continuous-Integration-Server für ein C ++ Projekt mit Unittest ++ als Test Bibliothek?

Wie genau hast du es einrichten?

Ich weiß, es hat, bevor sie auf Continuous Integration mehr Fragen, aber ich hoffe, dass dies ein einen engeren Anwendungsbereich hat.

EDIT: Ich werde ein bisschen auf klären, was ich suche. Ich habe bereits die Build auf fehlschlagen, wenn die Einheit-Tests fehlschlagen. Ich bin auf der Suche nach so etwas wie Hudsons JUnit-Unterstützung. Unittest ++ können XML-Berichte erstellen (siehe hier ). Also, vielleicht, wenn jemand weiß, wie diese Berichte zu übersetzen kompatibel zu JUnit, Hudson wird wissen, wie es zu essen?

War es hilfreich?

Lösung

Wir tun dies, aktiv an meinem Arbeitsplatz.

Zur Zeit verwenden wir eine Kür Software-Projekt an:

  • Überprüfen Sie unser Subversion-Repository für Updates alle 15 Minuten
  • Rufen Sie eine Windows-Batch-Datei zu reinigen und eine Lösung Datei erstellen
    • Projektdateien Erstellen und Ausführen von Unit-Tests als Post-Build-Ereignis
    • Unit-Test Ausfälle durch den Test main() zurückgegeben werden, so wie Buildfehler
    • behandelt

Ich habe auch getestet, eine Konfiguration, die die XmlTestReporter enthalten mit Unittest ++ verwendet, um die Ausgabedateien zu erzeugen. Die xUnit Plugin nativ unterstützt diese Ausgabe, zusammen mit einem anderen Ausgang können Sie konvertieren, obwohl ich die XSL-Datei, die sie mit ihm in Version 0.1.3 zu erhalten Dauern in der Testgeschichte aufgezeichnet ändern musste.

Es gibt eine Menge Dinge, die wir über unsere Integration verbessern möchten; die Build-Protokolle sind lang und hart, ohne Färbung oder Hervorhebung zu analysieren, etc., aber bisher hat es noch von Vorteil für uns.

Andere Tipps

überprüfte ich die xUnit Plugin, wie Patrick Johnmeyer vorgeschlagen in der akzeptierte Antwort. Die Vollständigkeit willen ist hier der Treibercode:

#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);
}

In Hudson Konfiguration überprüfen "Publish-Test-Tools führen Bericht" und verweisen Sie auf "file.xml"

Hudson hat jetzt eine CppUnit Plugin , die den Trick tun können .

Lange bevor ich begann Hudson zu verwenden, arbeitete ich an einem C ++ Projekt, bei dem wir verwenden cpp-Einheit-lite und CruiseControl-

Wir geändert Cpp-unit-lite JUnit wie XML-Report-Dateien zu generieren und CruiseControl- nahm die XML-Report-Dateien auf.

Sie können für Unittest das gleiche tun ++ und Hudson wird Abholung der Report-Dateien.

Aber das scheint wie eine Menge Arbeit. Werfen Sie einen Blick auf das Grundstück Plugin für Hudson. Sie können einen Skript die Anzahl der Fehler extrahieren / die Prüfungen von dem Unittest ++ Ausgabe und verwendet die Plot-Plugin ein einfaches Diagramm des Führens ziehen / Prüfungen nicht pro Build.

Nicht so schön wie die eingebaute Einheit Prüfbericht sondern etwas, das man schnell bekommen kann arbeiten.

Ich benutze hudson mit CppUnit und XML-Ausgabe. Die xml durch Xslt zu einer JUnit Ausgabe wie übersetzt. CppUnit Website bietet eine xslt, die CppUnit Ausgabe JUnit Ausgang umwandeln. Ich habe es ein bisschen, um gehackt MRE Details wie zu bekommen:

  • Namespaces als Pakete
  • Ausführungszeit

Sie können Ihre XML-Ausgabe umwandeln folgendes zu erhalten:

<?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>

Bei Erfolg: nur den Sub-Tag entfernen

Viele Grüße

Wir haben einen ähnlichen Ansatz in meinem Büro waren, mit der Ausnahme CxxTest statt Unittest ++ verwendet, und jetzt sind wir in dem Prozess zu Google weit überlegen (imho) Gtest Rahmen der Migration.

Mit CxxTest, haben wir etwas ähnliches, was Patrick J. vorgeschlagen, die im Grunde war es, einen Build-Schritt hinzuzufügen, die das Test-Suite-Programm über Ameise laufen würden und bewirken, dass die Build fehlschlagen, wenn alle Tests fehlschlagen. Der Nachteil dieses Ansatzes ist, wenn die Erstellung fehl aufgrund eines Prüfergebnisses, dann müssen Sie die Jagd durch die Ausgabe der Konsole gehen, um herauszufinden, was schief gelaufen ist. Auch verliert man die raffinierte Diagramme, die hudson erzeugen kann, wenn Ihr Test-Framework ausgeben kann JUnit-kompatible XML.

Einer der motivierenden Faktoren zu Gtest wechseln ist, dass es junit XML generiert, so in der Theorie, hudson die Testergebnisse analysieren kann und veröffentlichen sie in vernünftiger Weise. Wie auch immer, es sieht nicht so aus Unittest ++ etwas ähnliches erzeugt (bitte korrigiert mich wenn ich falsch liege), so könnte es ein strittiger Punkt sein, aber zumindest ist es in Ihren Build-Prozess zu integrieren wird sicherstellen, dass die Tests während laufen lassen baut.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top