Hudson、C++ 和 UnitTest++

Hudson, C++ and UnitTest++

提问by Gilad Naor

Has anyone used Hudsonas a Continuous-Integration server for a C++ project using UnitTest++as a testing library?

有没有人使用Hudson作为使用UnitTest++作为测试库的 C++ 项目的持续集成服务器？

How exactly did you set it up?

你具体是怎么设置的？

I know there have been several questions on Continuous Integration before, but I hope this one has a narrower scope.

我知道之前有几个关于持续集成的问题，但我希望这个问题的范围更窄。

EDIT: I'll clarify a bit on what I'm looking for. I already have the build set to fail when the Unit-Tests fail. I'm looking for something like Hudson's JUnit support. UnitTest++ can create XML reports (See here). So, perhaps if someone knows how to translate these reports to be JUnit compatible, Hudson will know how to eat it up?

编辑：我会澄清一下我在找什么。当单元测试失败时，我已经将构建设置为失败。我正在寻找类似 Hudson 的 JUnit 支持的东西。UnitTest++ 可以创建 XML 报告（请参阅此处）。那么，也许如果有人知道如何将这些报告翻译为与 JUnit 兼容，Hudson 会知道如何吃掉它？

采纳答案by Patrick Johnmeyer

We are actively doing this at my workplace.

我们正在我的工作场所积极地这样做。

Currently, we use a free-style software project to:

目前，我们使用自由风格的软件项目来：

• Check our Subversion repository for updates every 15 minutes
• Call a windows batch file to clean and build a solution file
  • Project files build and run unit tests as a post-build event
  • Unit test failures are returned by the test main(), thus treated as build errors

• 每 15 分钟检查一次我们的 Subversion 存储库以获取更新
• 调用 Windows 批处理文件来清理和构建解决方案文件
  • 项目文件构建和运行单元测试作为构建后事件
  • 单元测试失败由测试返回main()，因此被视为构建错误

I have also tested a configuration that uses the XmlTestReporter included with UnitTest++ to generate output files. The xUnit pluginnatively supports this output, along with any other output you can convert, although I had to change the XSL file that came with it in version 0.1.3 to get durations recorded in the test history.

我还测试了使用 UnitTest++ 附带的 XmlTestReporter 生成输出文件的配置。该xUnit的插件本身支持这个输出，你可以将任何其他输出一起，虽然我不得不改变与它排在0.1.3版本，以获得记录在测试历史持续时间XSL文件。

There are a lot of things we would like to improve about our integration; the build logs are long and hard to parse with no coloring or highlighting, etc., but so far it has still been beneficial to us.

关于我们的集成，我们希望改进很多方面；构建日志很长并且很难解析，没有着色或突出显示等，但到目前为止它仍然对我们有益。

回答by Gilad Naor

I checked the xUnitplugin, as Patrick Johnmeyer suggested in the accepted answer. For completeness sakes, here is the driver code:

我检查了xUnit插件，正如 Patrick Johnmeyer 在接受的答案中所建议的那样。为了完整起见，这里是驱动程序代码：

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

In Hudson configuration, check "Publish testing tools result report" and point it to "file.xml"

在 Hudson 配置中，选中“发布测试工具结果报告”并将其指向 "file.xml"

回答by Soo Wei Tan

Hudson now has a CppUnit pluginthat may do the trick.

Hudson 现在有一个CppUnit 插件可以解决这个问题。

回答by ewalshe

Long before I started to use Hudson, I worked on a C++ project where we used cpp-unit-lite and CruiseControl

早在我开始使用 Hudson 之前，我参与了一个 C++ 项目，我们使用了 cpp-unit-lite 和 CruiseControl

We altered Cpp-unit-lite to generate JUnit like XML report files and CruiseControl picked up the XML report files.

我们修改了 Cpp-unit-lite 来生成 JUnit 之类的 XML 报告文件，CruiseControl 获取 XML 报告文件。

You can do the same for UnitTest++ and Hudson will pickup the report files.

您可以对 UnitTest++ 执行相同的操作，Hudson 将获取报告文件。

However, that seems like a lot of work. Have a look at the plot plugin for Hudson. You can have a script extract the number of failing/passing tests from the UnitTest++ output and use the plot plugin to draw a simple graph of passing/failing tests per build.

然而，这似乎是很多工作。查看 Hudson 的绘图插件。您可以让脚本从 UnitTest++ 输出中提取失败/通过测试的数量，并使用绘图插件绘制每个构建的通过/失败测试的简单图形。

Not as nice as the in-built unit test report but something you can get working quickly.

不像内置的单元测试报告那么好，但你可以快速开始工作。

回答by ewalshe

I use hudson with CppUnit and xml output. The xml are translated by xslt to a JUnit output like. CppUnit site provides an xslt that convert CppUnit output to JUnit output. I have hacked it a bit in order to get mre details like :

我将 hudson 与 CppUnit 和 xml 输出一起使用。xml 由 xslt 转换为 JUnit 输出，例如。CppUnit 站点提供了一个将 CppUnit 输出转换为 JUnit 输出的 xslt。为了获得更多详细信息，我对其进行了一些修改，例如：

• namespaces as packages
• execution time

• 命名空间作为包
• 执行时间处理时间

you may transform your xml output to get the following:

您可以转换您的 xml 输出以获得以下内容：

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

In case of success : just remove the sub tag

如果成功：只需删除子标签

Regards

问候

回答by Nik Reiman

We've been using a similar approach at my office, except using cxxtest instead of UnitTest++, and now we're in the process to migrating to google's vastly superior (imho) gtest framework.

我们一直在我的办公室使用类似的方法，除了使用 cxxtest 而不是 UnitTest++，现在我们正在迁移到 google 非常优越的 (imho) gtest 框架。

With cxxtest, we did something similar to what Patrick J. suggested, which was to basically add a build step which would run the test suite program via ant and cause the build to fail if any tests fail. The disadvantage of this approach is when the build fails due to a test result, then you have to go hunting through the console output to figure out what went wrong. Also you loose the nifty charts which hudson can generate if your test framework can output junit-compatible XML.

使用 cxxtest，我们做了一些类似于 Patrick J. 建议的事情，即基本上添加一个构建步骤，该步骤将通过 ant 运行测试套件程序，并在任何测试失败时导致构建失败。这种方法的缺点是当构建由于测试结果而失败时，您必须通过控制台输出来找出问题所在。如果您的测试框架可以输出与 junit 兼容的 XML，那么您也会失去 hudson 可以生成的漂亮图表。

One of the motivating factors to switch to gtest is that it does generate junit XML, so in theory, hudson can parse the test results and publish them in a more sensible manner. Anyways, it doesn't look like UnitTest++ generates anything like this (please correct me if I'm wrong), so it might be a moot point, but at least integrating it into your build process will make sure that the tests get run during builds.

切换到 gtest 的动机之一是它确实生成了 junit XML，因此理论上，hudson 可以解析测试结果并以更明智的方式发布它们。无论如何，它看起来不像 UnitTest++ 生成这样的东西（如果我错了，请纠正我），所以这可能是一个有争议的问题，但至少将它集成到你的构建过程中将确保测试在建立。