Hudson, C ++ et UnitTest ++

Question

Quelqu'un a-t-il déjà utilisé Hudson comme serveur d'intégration continue pour un projet C ++ utilisant UnitTest ++ en tant que bibliothèque de test?

Comment l'avez-vous configuré exactement?

Je sais qu'il y a eu plusieurs questions sur l'intégration continue auparavant, mais j'espère que celle-ci a une portée plus étroite.

EDIT: Je vais clarifier un peu ce que je recherche. J'ai déjà le jeu de construction pour échouer lorsque les tests unitaires échouent. Je cherche quelque chose comme le support JUnit de Hudson. UnitTest ++ peut créer des rapports XML (voir ici ). Donc, si quelqu'un sait comment traduire ces rapports comme étant compatibles JUnit, Hudson saura comment en manger?

Answer 1

Nous le faisons activement sur mon lieu de travail.

Nous utilisons actuellement un projet de logiciel libre pour:

• Consultez notre référentiel Subversion pour des mises à jour toutes les 15 minutes
• Appeler un fichier de commandes Windows pour nettoyer et créer un fichier de solution
  • Les fichiers de projet construisent et exécutent des tests unitaires en tant qu'événement post-génération
  • Les échecs de test d'unité sont renvoyés par le test main () , ainsi traités comme des erreurs de construction

J'ai également testé une configuration utilisant le XmlTestReporter fourni avec UnitTest ++ pour générer des fichiers de sortie. Le plug-in xUnit prend en charge cette sortie de manière native, ainsi que toute autre sortie possible. convertir, bien que j’ai dû changer le fichier XSL fourni avec la version 0.1.3 pour que les durées soient enregistrées dans l’historique des tests.

Nous souhaitons améliorer beaucoup notre intégration; les journaux de construction sont longs et difficiles à analyser, sans coloration ni surbrillance, etc., mais jusqu'à présent, cela nous a toujours été bénéfique.

Answer 2

J'ai vérifié le plug-in xUnit , comme l'a suggéré Patrick Johnmeyer dans le réponse acceptée. Par souci d'exhaustivité, voici le code du pilote:

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

Dans la configuration Hudson, cochez la case "Publier le résultat des outils de test". et pointez-le sur "file.xml"

Answer 3

Hudson a maintenant un plug-in CppUnit qui peut faire l'affaire. .

Answer 4

Bien avant de commencer à utiliser Hudson, je travaillais sur un projet C ++ dans lequel nous utilisions cpp-unit-lite et CruiseControl

Nous avons modifié Cpp-unit-lite pour générer JUnit comme des fichiers de rapport XML et CruiseControl a récupéré les fichiers de rapport XML.

Vous pouvez faire la même chose pour UnitTest ++ et Hudson récupérera les fichiers de rapport.

Cependant, cela semble être beaucoup de travail. Jetez un coup d'œil au plugin complot pour Hudson. Vous pouvez demander à un script d'extraire le nombre de tests ayant échoué / réussi de la sortie UnitTest ++ et d'utiliser le plug-in de tracé pour tracer un graphique simple de réussite ou d'échec des tests par construction.

Pas aussi bien que le rapport de test unitaire intégré, mais quelque chose que vous pouvez travailler rapidement.

Answer 5

J'utilise Hudson avec CppUnit et une sortie XML. Les xml sont traduits par xslt en une sortie JUnit comme. Le site CppUnit fournit un xslt qui convertit la sortie CppUnit en sortie JUnit. Je l'ai piraté un peu afin d'obtenir plus de détails tels que:

• espaces de noms en tant que packages
• temps d'exécution

vous pouvez transformer votre sortie XML pour obtenir ce qui suit:

<?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 cas de succès: supprimez simplement la sous-balise

Cordialement

Answer 6

Nous avons utilisé une approche similaire dans mon bureau, à l'exception de l'utilisation de cxxtest au lieu de UnitTest ++, et nous sommes maintenant en train de migrer vers le cadre extrêmement supérieur (imho) gtest de Google.

Avec cxxtest, nous avons fait quelque chose de similaire à ce que Patrick J. a suggéré, consistant à ajouter une étape de construction qui exécuterait le programme de suite de tests via ant et provoquerait l’échec de la construction si des tests échouaient. L'inconvénient de cette approche est que lorsque la construction échoue en raison d'un résultat de test, vous devez alors rechercher la sortie de la console pour déterminer ce qui ne va pas. Vous perdez également les graphiques astucieux que hudson peut générer si votre infrastructure de test peut générer du XML compatible Junit.

L’un des facteurs de motivation pour passer à gtest est le fait qu’il génère un XML Junit. En théorie, Hudson peut analyser les résultats des tests et les publier de manière plus rationnelle. Quoi qu'il en soit, UnitTest ++ ne semble pas générer quoi que ce soit du genre (corrigez-moi si je me trompe), cela pourrait donc être un point discutable, mais au moins son intégration dans votre processus de construction garantira que les tests sont exécutés pendant construit.