Hudson, C ++ y UnitTest ++

Question

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

¿Cómo lo configuraste exactamente?

Sé que ha habido varias preguntas sobre Integración Continua antes, pero espero que esta tenga un alcance más limitado.

EDITAR: Voy a aclarar un poco sobre lo que estoy buscando. Ya tengo el conjunto de compilación para fallar cuando fallan las pruebas unitarias. Estoy buscando algo como el soporte JUnit de Hudson. UnitTest ++ puede crear informes XML (consulte aquí ). Entonces, tal vez si alguien sabe cómo traducir estos informes para que sean compatibles con JUnit, ¿Hudson sabrá cómo comerlo?

Answer 1

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 obtener actualizaciones cada 15 minutos
• Llame a un archivo por lotes de Windows para limpiar y crear un archivo de solución
  • Los archivos de proyecto compilan y ejecutan pruebas unitarias como un evento posterior a la compilación
  • Los errores de prueba de la unidad son devueltos por la prueba main () , por lo que se tratan como errores de compilación

También he probado una configuración que utiliza el XmlTestReporter incluido con UnitTest ++ para generar archivos de salida. El xUnit plugin 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 él en la versión 0.1.3 para obtener las 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 ni resaltar, etc., pero hasta el momento aún nos ha resultado beneficioso.

Answer 2

Revisé el complemento xUnit , como sugirió Patrick Johnmeyer 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 apúntelo a "file.xml"

Answer 3

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

Answer 4

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

Hemos modificado Cpp-unit-lite para generar archivos de informe XML de tipo JUnit y CruiseControl recogió los archivos de informe XML.

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

Sin embargo, eso parece mucho trabajo. Echa un vistazo al plugin de trama para Hudson. Puede hacer que un script extraiga el número de pruebas de aprobación / aprobación de la salida UnitTest ++ y utilice el complemento de trazado para dibujar un gráfico simple de pruebas de aprobación / aprobación por compilación.

No es tan bueno como el informe de prueba de unidad incorporado, pero es algo que puede hacer que funcione rápidamente.

Answer 5

Uso hudson con CppUnit y salida xml. Los xml son traducidos por xslt a una salida JUnit como. El sitio CppUnit proporciona un xslt que convierte la salida CppUnit en la 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

Answer 6

Hemos estado utilizando 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 enormemente superior de Google.

Con cxxtest, hicimos algo similar a lo que sugirió Patrick J., que consistía básicamente en agregar un paso de compilación que ejecutara el programa de la suite de pruebas a través de una hormiga y que la compilación fallara si fallaban las pruebas. La desventaja de este enfoque es que cuando la compilación falla debido a un resultado de prueba, entonces tiene que buscar en la salida de la consola para descubrir qué fue lo que falló. También pierde los ingeniosos gráficos 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 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íjame si me equivoco), por lo que podría ser un punto discutible, pero al menos integrarlo en su proceso de compilación asegurará que las pruebas se ejecuten durante compilaciones.