Hudson, C ++ e UnitTest ++

Question

Qualcuno ha usato Hudson come server di integrazione continua per un progetto C ++ usando UnitTest ++ come libreria di test?

Come lo hai impostato esattamente?

So che in precedenza ci sono state diverse domande sull'integrazione continua, ma spero che questa abbia un ambito più ristretto.

EDIT: chiarirò un po 'quello che sto cercando. Ho già impostato la build in modo che fallisca quando falliscono i test unitari. Sto cercando qualcosa come il supporto JUnit di Hudson. UnitTest ++ può creare report XML (vedi qui ). Quindi, forse se qualcuno sa come tradurre questi rapporti in modo che siano compatibili con JUnit, Hudson saprà come mangiarlo?

Answer 1

Lo stiamo facendo attivamente sul mio posto di lavoro.

Attualmente, utilizziamo un progetto software in stile libero per:

• Controlla il nostro repository Subversion per gli aggiornamenti ogni 15 minuti
• Chiama un file batch di Windows per pulire e creare un file di soluzione
  • I file di progetto compilano ed eseguono unit test come evento post-build
  • Gli errori del test unitario vengono restituiti dal test main () , quindi trattati come errori di build

Ho anche testato una configurazione che utilizza XmlTestReporter incluso in UnitTest ++ per generare file di output. Il xUnit plugin supporta nativamente questo output, insieme a qualsiasi altro output che puoi convertire, anche se ho dovuto modificare il file XSL fornito con esso nella versione 0.1.3 per registrare le durate nella cronologia dei test.

Ci sono molte cose che vorremmo migliorare riguardo alla nostra integrazione; i log di compilazione sono lunghi e difficili da analizzare senza colorazione o evidenziazione, ecc., ma finora ci sono ancora stati utili.

Answer 2

Ho controllato il plug-in xUnit , come suggerito da Patrick Johnmeyer nel risposta accettata. Per completezza, ecco il codice del driver:

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

Nella configurazione di Hudson, seleziona " Pubblica rapporto risultati strumenti di test " e puntalo su "file.xml"

Answer 3

Hudson ora ha un plugin CppUnit che potrebbe fare il trucco .

Answer 4

Molto prima di iniziare a usare Hudson, ho lavorato su un progetto C ++ in cui abbiamo usato cpp-unit-lite e CruiseControl

Abbiamo modificato Cpp-unit-lite per generare JUnit come file di report XML e CruiseControl ha raccolto i file di report XML.

Puoi fare lo stesso per UnitTest ++ e Hudson raccoglierà i file del rapporto.

Tuttavia, sembra un sacco di lavoro. Dai un'occhiata al plugin di trama per Hudson. Puoi avere uno script per estrarre il numero di test falliti / superati dall'output UnitTest ++ e utilizzare il plug-in per tracciare un semplice grafico dei test superati / falliti per build.

Non carino come il rapporto di test unitario incorporato, ma qualcosa su cui puoi far funzionare rapidamente.

Answer 5

Uso hudson con CppUnit e output XML. I file XML vengono tradotti da xslt in un output JUnit come. Il sito CppUnit fornisce un xslt che converte l'output CppUnit in output JUnit. L'ho hackerato un po 'per ottenere maggiori dettagli come:

• spazi dei nomi come pacchetti
• tempo di esecuzione

puoi trasformare l'output xml per ottenere quanto segue:

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

In caso di successo: basta rimuovere il tag secondario

Saluti

Answer 6

Abbiamo utilizzato un approccio simile nel mio ufficio, ad eccezione di cxxtest invece di UnitTest ++, e ora stiamo procedendo alla migrazione al framework gtest enormemente superiore (imho) di Google.

Con cxxtest, abbiamo fatto qualcosa di simile a quanto suggerito da Patrick J., che consisteva essenzialmente nell'aggiungere una fase di compilazione che avrebbe eseguito il programma della suite di test tramite formica e avrebbe causato il fallimento della compilazione in caso di esito negativo di qualsiasi test. Lo svantaggio di questo approccio è quando la build fallisce a causa di un risultato del test, quindi devi andare a caccia attraverso l'output della console per capire cosa è andato storto. Inoltre perdi i grafici ingegnosi che hudson può generare se il tuo framework di test può generare XML compatibile con junit.

Uno dei fattori motivanti per passare a gtest è che genera junit XML, quindi in teoria hudson può analizzare i risultati dei test e pubblicarli in modo più sensato. Comunque, non sembra che UnitTest ++ generi qualcosa del genere (per favore correggimi se sbaglio), quindi potrebbe essere un punto controverso, ma almeno integrarlo nel tuo processo di compilazione farà in modo che i test vengano eseguiti durante costruisce.