Hudson, C++ y UnitTest++

Revisé el complemento xUnit, como sugirió Patrick Johnmeyer en la respuesta aceptada. Por el bien de la integridad, aquí está el código del controlador:

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

En la configuración de Hudson, marque "Publicar informe de resultados de herramientas de prueba" y apunte a "file.xml"

Hudson ahora tiene un CppUnit plugin que puede hacer el truco.

Mucho antes de empezar a usar Hudson, trabajé en un proyecto de C++ donde usamos cpp-unit-lite y CruiseControl

Alteramos Cpp-unit-lite para generar archivos de informes XML como JUnit y CruiseControl recogió los archivos de informes XML.

Puede hacer lo mismo para UnitTest++ y Hudson recogerá los archivos de informe.

Sin embargo, eso parece mucho trabajo. Echa un vistazo a la parcela plugin para Hudson. Puede hacer que un script extraiga el número de pruebas fallidas/pasadas de la UnitTest++ de salida y utilizar el plugin plot para dibujar un gráfico simple de pasar / pruebas fallidas por compilación.

No es tan agradable como el informe de prueba de unidad incorporado, pero algo que puede trabajar rápidamente.

Utilizo hudson con CppUnit y salida xml. Los xml son traducidos por xslt a una salida JUnit como. CppUnit site proporciona un xslt que convierte la salida de CppUnit a la salida de JUnit. He hackeado un poco con el fin de obtener mre detalles como:

• espacios de nombres como paquetes
• tiempo de ejecución

Puede transformar su salida xml para obtener lo siguiente:

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

En caso de éxito: simplemente elimine la etiqueta sub

Saludos

Hemos estado usando un enfoque similar en mi oficina, excepto el uso de cxxtest en lugar de UnitTest++, y ahora estamos en el proceso de migrar al marco gtest de Google, muy superior (imho).

Con cxxtest, hicimos algo similar a lo que sugirió Patrick J., que era básicamente agregar un paso de compilación que ejecutaría el programa test suite a través de ant y causaría que la compilación fallara si alguna prueba fallaba. La desventaja de este enfoque es que cuando la compilación falla debido a un resultado de prueba, entonces usted tengo que ir a cazar a través de la salida de la consola para averiguar qué salió mal. También pierde los gráficos ingeniosos que Hudson puede generar si su marco de prueba puede generar XML compatible con junit.

Uno de los factores motivadores para cambiar a gtest es que genera junit XML, por lo que en teoría, Hudson puede analizar los resultados de la prueba y publicarlos de una manera más sensata. De todos modos, no parece que UnitTest++ genere algo como esto (corríjame si me equivoco), por lo que podría sea un punto discutible, pero al menos integrarlo en su proceso de compilación se asegurará de que las pruebas se ejecuten durante las compilaciones.