我们有一个大型自动化集成测试套件的“问题”。虽然我们的构建时间是合理的(< 1 小时)，但测试通常需要超过 6 小时才能完成。
虽然在我们的构建运行中测试这么大的功能 block 很棒，但这显然是实现 CI 的障碍，我发现这对于将源代码树保持在“始终可构建”状态非常有帮助。
我查看过 this one 等讨论主题，其中详细说明了区别。
这引出了几个问题:
CI 是否规定或推荐单元与集成测试自动化？我过去曾听说过 Unit-only，但在快速搜索中没有找到任何此类陈述(或理由)。
对于组合构建 + 自动化测试时间/比率来为团队提供有效 CI 的“最佳实践”是什么？我的直觉告诉我，最坏的情况应该是 < 2 小时，真正有效的可能是 < 1 小时。理论上，我们可以将测试拆分为并行运行，并可能让它们在 2 小时内运行，但这仍然需要 3 小时的运行时间。
从长期运行的夜间构建 + 集成测试到 CI 的最佳前进方式是什么？我正在考虑一个仅包含一些骨架单元测试的 CI 构建，以及继续进行集成测试的夜间构建。
也欢迎任何工具建议(仅限 Windows 的 C#/C++ 代码库)
最佳答案
For most projects, however, the XP guideline of a ten minute build is perfectly within reason. Most of our modern projects achieve this. It's worth putting in concentrated effort to make it happen, because every minute you reduce off the build time is a minute saved for each developer every time they commit. Since CI demands frequent commits, this adds up to a lot of time.
Source: http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast
为什么需要 6 个小时？你有多少测试？单元测试与集成测试的比例是多少？您可能有更多的集成测试，或者您的单元测试不是真正的单元。您的单元测试是否涉及数据库？这可能是问题所在。
6 小时是一个很长的时间。上面的文章有一些提示。
关于unit-testing - 每晚构建与持续集成 : Long-Running Automated Tests，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4899681/