【问题标题】:running unit-tests after every successful compilation每次成功编译后运行单元测试
【发布时间】:2017-06-06 13:15:33
【问题描述】:

考虑带有静态库项目和带有单元测试的控制台应用程序的 Visual Studio C++ 解决方案。应用程序构建后步骤是 "$(TargetDir)$(TargetFileName)" 以在每次成功编译时自动运行测试。

当编译成功但测试失败时,有时我想调试它们,所以我需要从 VS 运行它们。问题是如果测试失败,构建也会被认为失败,因此 VS 拒绝运行。

一个不理想的解决方案是启用一个选项

所以当你尝试运行失败的构建时,你会得到

(该选项默认为on,但迟早每个人都会点击“不再显示此对话框”)

这并不理想,因为它令人困惑,它会再次触发构建(编译成功时会跳过但会再次运行测试,并且该选项是全局的,这意味着它适用于您的所有项目,即使是那些不需要它的项目。它是当然不是什么大不了的事,只是想知道人们是否对此有一些聪明的技巧。

例如,C# 项目构建事件有一个选项“当构建更新项目输出时” - 非常适合在每次编译后进行单元测试。

项目是跨平台的,所以VS测试框架不适用。

【问题讨论】:

  • 为什么VS测试框架不适用?您在这里要求一个不可避免的特定于平台的解决方案(假设您没有在其他平台上使用 MSBuild)。
  • @Sneftel:单元测试是跨平台的,我们使用谷歌测试。大多数开发都发生在 VS 中的 Windows 上(我认为这是非常流行的设置)。我对 VS 测试框架的了解有限,你知道它在这里有什么帮助吗?
  • 如何让单元测试成为一个依赖于主项目的独立项目?如果构建失败,主项目仍将标记为已构建。
  • @VTT:已经是:a static lib project and a console app with unit-tests
  • 我的意思是你创建了另一个依赖于这个控制台应用程序并实际运行测试的项目。

标签: c++ visual-studio unit-testing


【解决方案1】:

我建议添加由“运行单元测试”命令组成的“makefile 项目”(文件 -> 添加 -> 新项目 -> Visual C++ -> 常规 -> Makefile 项目)。并使测试应用本身不包含自运行。

那么你的整个解决方案会因测试失败而失败,但测试本身会成功。

不过,你的情况并不常见。通常,除了测试应用程序之外,解决方案将包含“有用的工作应用程序”,然后单元测试将进入“有用的工作应用程序”的预构建(这也将依赖于测试应用程序)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-01-26
    • 2012-11-26
    • 1970-01-01
    • 2015-01-09
    • 2012-08-07
    • 1970-01-01
    • 2021-12-18
    • 1970-01-01
    相关资源
    最近更新 更多