Question

MODIFIER : ce problème a été résolu par Google dans gtest 1.4.0. voir le rapport de bogue d'origine pour plus d'informations.

Je suis récemment passé à gtest pour mon framework de test C ++, et une grande fonctionnalité que je ne suis actuellement pas en mesure d'utiliser est la possibilité de générer des rapports de test XML de style JUnit, qui pourraient ensuite être lus par notre équipe Hudson. construire un serveur.

La sortie XML générée par la suite de tests gtest a l'air légitime:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite tests="370" failures="0" disabled="0" errors="0" time="45.61" name="AllTests">
    <testsuite name="application" tests="7" failures="0" disabled="0" errors="0" time="8.953">
        <testcase name="zero_tasks_on_bootup" status="run" time="0" classname="application" />
...etc.
    </testsuite>
</testsuite>

J'ai également essayé d'ajouter une tâche JUnitReport à mon script de génération ant, ce qui fonctionne bien et génère du XML comme suit:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite tests="370" failures="0" disabled="0" errors="0" time="45.61" name="AllTests">
    <testsuite name="application" tests="7" failures="0" disabled="0" errors="0" time="8.953">
        <testcase name="zero_tasks_on_bootup" status="run" time="0" classname="application" />
    ...etc.
    </testsuite>
 </testsuite>

Le problème est que, chaque fois que je demande à ant de publier les résultats du test JUnit, puis de le diriger vers le résultat brut du test XML ou le résultat compilé généré dans la tâche ant JUnitReport, hudson se plaint toujours de ne pas y trouver de résultats de test. .

Je ne suis pas un gars Java, je ne peux donc pas savoir ce qui se passe ici, et je ne trouve pas d'exemple de l'apparence que devrait avoir le fichier XML de JUnit. Quelqu'un peut-il m'aider à me diriger dans la bonne direction?

Était-ce utile?

La solution 2

Modifier : le test de Google a résolu ce problème, qui est inclus dans la version 1.4.0 de gtest. Consultez le rapport de bogue d'origine pour plus d'informations.

Bah! J'ai finalement trouvé la cause de ce problème - c'est parce que gtest produit un fichier XML géant pour tous les résultats de test et que hudson attend un rapport de test XML par classe. J'ai écrit un script Perl pour contourner ce problème . Pour l'utiliser, vous devez créer une cible dans votre script ant xml qui ressemble à ceci:

<target name="runtests">
  <exec executable="wherever/${ant.project.name}Test" failonerror="false" dir="tests">
    <arg value="--gtest_output=xml:${build.dir}\reports\${ant.project.name}.xml"/>
  </exec>
  <!-- Workaround for broken gtest output -->
  <mkdir dir="${build.dir}/reports/output"/>
  <exec executable="perl" failonerror="false" dir="tests">
  <arg value="gtest-hudson.pl"/>
    <arg value="${build.dir}/reports/${ant.project.name}.xml"/>
    <arg value="${build.dir}/reports/output"/>
  </exec>
</target>

Pour une raison quelconque, gtest n'aime pas non plus le style erroné de slash qui lui est transmis par ant. C'est pourquoi j'ai créé mon exec pour Windows uniquement, mon serveur Hudson étant exécuté sur un serveur Windows. Changez évidemment en '/' pour unix.

J'ai également déposé un problème à ce sujet sur la page gtest. , ainsi que sur l'outil de suivi des problèmes de hudson J'espère donc que l'une des deux équipes abordera la question, car je n'ai pas assez de temps pour intervenir et faire un patch moi-même ... même si cela ne se règle pas dans un proche avenir, je pourrais je dois juste. ;)

Autres conseils

Voici comment je le fais:

    <target name="junit" depends="compile-tests" description="run all unit tests">
      <mkdir dir="${reports}"/>
      <junit haltonfailure="false">
         <jvmarg value="-Xms128m"/>
         <jvmarg value="-Xmx128m"/>
         <classpath>
            <path refid="project.classpath"/>
         </classpath>
         <formatter type="xml"/>
         <batchtest fork="yes" todir="${reports}">
            <fileset dir="${test}/classes">
                <include name="**/*Test*.class"/>
            </fileset>
         </batchtest>
      </junit>
  </target>

  <target name="generate-reports" depends="junit" description="create JUnit test HTML reports">
      <mkdir dir="${reports}"/>
      <junitreport todir="${reports}">
          <fileset dir="${reports}">
              <include name="TEST-*.xml"/>
          </fileset>
          <report format="frames" todir="${reports}"/>
      </junitreport>
  </target>

Je suis presque certain que ce n'est pas un problème d'analyse du XML, mais un problème de recherche des fichiers XML. Si vous utilisez un chemin relatif dans la configuration Hudson, assurez-vous d’indiquer clairement dans quel répertoire il est relatif (je pense me souvenir que cela n’est pas évident dans certaines circonstances).

Pour ce qui est des exemples de ce à quoi les fichiers XML JUnit sont censés ressembler, bonne chance avec cela. Ce n'est pas spécifié avec précision nulle part. Différents outils ont des dialectes différents. Cela dit, Hudson les reconnaît tous très bien. Je pense que ce sont les développeurs de JUnitReport qui ont introduit le format XML. Si vous utilisez ce format, votre décision sera aussi canonique que possible.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top