Hudson, C ++ ++ e UnitTest

Question

Alguém já usou Hudson como um servidor de integração contínua para um projeto C ++ usando UnitTest ++ como uma biblioteca de testes?

Como exatamente você configurá-lo?

Eu sei que tem havido várias perguntas sobre integração contínua antes, mas espero que este tem um âmbito mais restrito.

EDIT: Eu vou esclarecer um pouco sobre o que eu estou procurando. Eu já tenho o conjunto compilação falhar quando a unidade-testes falham. Eu estou procurando algo como suporte JUnit de Hudson. UnitTest ++ pode criar relatórios XML (consulte aqui ). Então, talvez se alguém sabe como traduzir esses relatórios para ser JUnit compatível, Hudson vai saber como comê-lo acima?

Answer 1

Estamos ativamente fazendo isso no meu local de trabalho.

Atualmente, utilizamos um projeto de software de estilo livre para:

• Verifique nosso repositório Subversion para atualizações a cada 15 minutos
• Chame um arquivo janelas lote para limpar e construir um arquivo de solução
  • Project arquivos testes de build e unidade funcione como um evento pós-compilação
  • falhas de teste de unidade são retornados pelo main() teste, portanto, tratados como erros de compilação

Eu também testou uma configuração que usa o XmlTestReporter incluído com UnitTest ++ para gerar arquivos de saída. A xUnit plug-in suporta nativamente esta saída, juntamente com qualquer outra saída que puder converso, embora eu tive que mudar o arquivo XSL que veio com ele na versão 0.1.3 para obter durações registrados na história de teste.

Há um monte de coisas que gostariam de melhorar a nossa integração; os logs de construção são longos e difíceis de analisar com nenhuma coloração ou destacando, etc., mas até agora ele ainda tem sido benéfico para nós.

Answer 2

Eu verifiquei o xUnit plugin, como Patrick Johnmeyer sugerido na resposta aceita. Pelo amor de completude, aqui é o código do driver:

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

Configuração no Hudson, marque a opção "Publicar testando ferramentas resultam relatório" e aponte para "file.xml"

Answer 3

Hudson tem agora um CppUnit plug-in que podem fazer o truque .

Answer 4

Muito antes de eu comecei a usar Hudson, eu trabalhei em um projeto de C ++ onde costumávamos CPP-unit-lite e CruiseControl

Nós alteradas CPP-unidade-lite para gerar JUnit como arquivos de relatório XML e CruiseControl pegou os arquivos de relatório XML.

Você pode fazer o mesmo para UnitTest ++ e Hudson irá pegar os arquivos de relatório.

No entanto, isso parece ser um monte de trabalho. Ter um olhar para o plugin enredo para Hudson. Você pode ter um extrato roteiro o número de falha / passando testes de saída do UnitTest ++ e usar o plugin trama para desenhar um gráfico simples de aprovação / reprovação testes per compilação.

Não tão bom quanto o embutido relatório de teste de unidade, mas algo que você pode começar a trabalhar rapidamente.

Answer 5

Eu uso hudson com CppUnit e saída de xml. A XML são traduzidos por XSLT para uma saída JUnit semelhantes. local CppUnit fornece um XSLT que a saída convertido CppUnit para a saída JUnit. Tenho cortado um pouco a fim de obter MRE detalhes como:

• namespaces como pacotes
• tempo de execução

Você pode transformar a sua saída XML para obter o seguinte:

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

Em caso de sucesso: basta remover o sub tag

Saudações

Answer 6

Estamos usando uma abordagem semelhante no meu escritório, excepto o uso de cxxtest vez de UnitTest ++, e agora estamos no processo de migrar para o Google muito superiores (IMHO)-quadro gtest.

Com cxxtest, fizemos algo semelhante ao que Patrick J. sugeriu, que foi adicionar basicamente um passo de compilação que iria executar o programa conjunto de testes via formiga e causar a compilação falhar se algum dos testes falhar. A desvantagem dessa abordagem é quando a compilação falhar devido a um resultado de teste, então você tem que ir caçar através da saída do console para descobrir o que deu errado. Além disso, você solta os gráficos bacanas que hudson pode gerar se o seu teste de enquadramento lata saída junit compatível com XML.

Um dos fatores de motivação para mudar para gtest é que ele faz gerar XML junit, portanto, em teoria, hudson pode analisar os resultados do teste e publicá-los de uma forma mais sensata. De qualquer forma, ele não se parece com UnitTest ++ gera nada parecido com isso (por favor me corrijam se eu estiver errado), por isso pode ser um ponto discutível, mas, pelo menos, integrando-os em seu processo de construção irá certificar-se de que os testes se executado durante constrói.