Hudson, C ++ ++ e UnitTest
-
03-07-2019 - |
Pergunta
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?
Solução
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.
Outras dicas
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"
Hudson tem agora um CppUnit plug-in que podem fazer o truque .
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.
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
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.