c++ unit-testing continuous-integration hudson jenkins

Hudson, C++ y UnitTest++



unit-testing continuous-integration (6)

¿Alguien ha usado Hudson como un servidor de Integración Continua para un proyecto de C ++ usando UnitTest++ como una biblioteca de prueba?

¿Cómo exactamente lo configuraste?

Sé que ha habido varias preguntas sobre integración continua antes, pero espero que este tenga un alcance más estrecho.

EDIT: aclararé un poco sobre lo que estoy buscando. Ya tengo la compilación configurada para fallar cuando fallan las Pruebas unitarias. Estoy buscando algo así como el soporte JUnit de Hudson. UnitTest ++ puede crear informes XML (ver here ). Entonces, ¿tal vez si alguien sabe cómo traducir estos informes para ser compatible con JUnit, Hudson sabrá cómo comerlo?


Estamos haciendo esto activamente en mi lugar de trabajo.

Actualmente, utilizamos un proyecto de software de estilo libre para:

  • Consulte nuestro repositorio de Subversion para actualizaciones cada 15 minutos
  • Llamar a un archivo por lotes de Windows para limpiar y crear un archivo de solución
    • Los archivos de proyecto crean y ejecutan pruebas unitarias como un evento posterior a la construcción
    • Las pruebas fallidas de la unidad son devueltas por la prueba main() , por lo tanto tratadas como errores de compilación

También probé una configuración que usa el XmlTestReporter incluido con UnitTest ++ para generar archivos de salida. El complemento xUnit admite de forma nativa esta salida, junto con cualquier otra salida que pueda convertir, aunque tuve que cambiar el archivo XSL que venía con ella en la versión 0.1.3 para obtener duraciones registradas en el historial de pruebas.

Hay muchas cosas que nos gustaría mejorar sobre nuestra integración; los registros de compilación son largos y difíciles de analizar sin colorear o resaltar, etc., pero hasta ahora han sido beneficiosos para nosotros.


Hemos utilizado un enfoque similar en mi oficina, excepto que utilizamos cxxtest en lugar de UnitTest ++, y ahora estamos en el proceso de migrar al marco de Google (inmensamente) más avanzado.

Con cxxtest, hicimos algo similar a lo que sugirió Patrick J., que consistía básicamente en agregar un paso de compilación que ejecutaría el programa de suite de prueba a través de ant y haría que la compilación fallara si fallara alguna prueba. La desventaja de este enfoque es cuando falla la compilación debido a un resultado de la prueba, luego debe buscar en la salida de la consola para descubrir qué salió mal. También se pierden los cuadros ingeniosos que hudson puede generar si su marco de prueba puede dar salida a XML compatible con Junit.

Uno de los factores motivadores para cambiar a gtest es que genera un XML junit, 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ígeme si estoy equivocado), por lo que podría ser un punto discutible, pero al menos integrarlo en tu proceso de compilación asegurará que las pruebas se ejecuten durante construcciones



Mucho antes de comenzar a utilizar Hudson, trabajé en un proyecto de C ++ donde utilizamos cpp-unit-lite y CruiseControl

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

Puede hacer lo mismo con UnitTest ++ y Hudson recuperará los archivos de informe.

Sin embargo, eso parece mucho trabajo. Eche un vistazo al plugin de la parcela para Hudson. Puede hacer que una secuencia de comandos extraiga el número de pruebas de falla / aprobación de la salida de UnitTest ++ y use el plugin de trazado para dibujar un gráfico simple de las pruebas de aprobación / falla por compilación.

No es tan bueno como el informe de prueba de la unidad incorporada, pero es algo que puede trabajar rápidamente.


Yo uso hudson con CppUnit y salida xml. Los xml se traducen por xslt a una salida JUnit como. El sitio CppUnit proporciona un xslt que convierte la salida CppUnit en salida JUnit. Lo he pirateado un poco para obtener 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 secundaria

Saludos


Revisé el plugin xUnit , como Patrick Johnmeyer sugirió en la respuesta aceptada. Para completar, 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 "file.xml" a "file.xml"