我们遇到了大型自动化集成测试套件的“问题”。虽然我们的构建时间是合理的（<1小时），但测试通常采用＆gt; 6个小时完成。
虽然在我们的构建运行中测试这一大块功能很棒，但它显然是实现CI的障碍，我发现这对于将源树保持在“始终可构建”状态非常有帮助。
我已经审查了像this one这样的讨论话题，详细阐述了区别。
这引出了一些问题：
CI是否规定或推荐单元与集成测试自动化？我过去听说过Unit-only，但是我没有在快速搜索中找到任何这样的陈述（或理由）。
组合构建+自动化测试时间/比率为团队提供有效CI的良好“最佳实践”是什么？我的直觉告诉我，这应该是＆lt; 2小时是最坏的情况，可能＆lt; 1小时才真正有效。从理论上讲，我们可以将测试分解为并行运行，并且可能让它们在2小时内运行，但这仍然是3小时运行。
从长期运行的Nightly Builds + Integration测试到CI，最好的方法是什么？我正在考虑只使用一些骨架单元测试的CI构建，以及继续进行集成测试的夜间构建。
也欢迎任何工具建议（仅限Windows的C＃/ C ++代码库）
答案 0 :(得分：14)
对于大多数项目，XP 十分钟构建的准则是 完全在理性之内。大多数人 现代项目实现了这一目标。这是 值得集中精力 让它成为现实，因为每一个 你减少了构建时间 为每个开发者保存一分钟 每次他们承诺。自CI 需要经常提交，这就相加了 很多时候。
来源： http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast
为什么需要6个小时？你有多少次测试？单元测试与集成测试的比例是多少？你可能有更多的综合测试或你的单元测试不是真正的单位。您的单元测试是否接触数据库？这可能是问题所在。
6小时是很长的时间。上面的文章有一些提示。
答案 1 :(得分：5)
这里有一些事情。
一般来说，你会有许多构建，一个编译和编译。运行单元测试，运行单元测试并运行本地验收测试，运行集成测试。
你肯定不需要一个可以完成所有事情的构建。
你的构建时间听起来很长 - 请记住，这里的重点是提供快速反馈，说明出现问题。我对你的项目了解不多 - 但我认为你应该把你的编译和单元测试建立到不到两到三分钟。这在所有但非常大的项目中都是完全可以实现的，所以如果你的单元测试花费时间，那么就该开始询问原因了。
6小时也是很长时间。你确定你的测试正在测试正确的东西吗？你有太多广泛的测试范围吗？你在测试代码中没有很好地模拟异步这个事实，你到处都在使用“sleep（）”来构成吗？你应该掌握Jez Humbles的书“持续交付”，并看看成长对象软件如何编写单元/集成测试。 GOOS使用Java作为实现语言，但所有概念都是相同的。