您如何围绕将单元测试添加到构建中来定制您的开发流程？ [关闭]答案

【问题标题】：How do you tailor your dev process around adding unit tests to the build? [closed]您如何围绕将单元测试添加到构建中来定制您的开发流程？ [关闭]
【发布时间】：2010-09-23 21:56:49
【问题描述】：

我在工作中遇到了一种情况，有人建议将我们的单元测试添加到 Cruise Control 持续构建过程中。单元测试将作为另一个项目添加到 CC 中，这样我们就会有一个 "Normal Build" 项目和一个 "Build and Test" 项目。我们目前使用“正常构建”流程来 a) 确保没有开发人员破坏构建，并且 b) 确保在将发布即将推送到 QA/Production 时构建没有破坏。

通过将单元测试添加到流程中，我们可以 a) 在单元测试被破坏时收到通知，以便我们检查以确保它不是我们编写的，并且 b) 确保在 a) 之前没有单元失败build 被发布到 QA/Production。所以我了解其中的好处，但我仍然担心这将如何影响我们的开发过程。这是我看到的场景......

当前进程...

构建服务器构建 Cruise Control “正常构建”项目
指示灯变红（在巡航控制中）当构建失败时
被指责的开发者得到了一个巨魔

新流程...

为“构建和测试”添加了另一个 CC 项目（现在是两个项目）
“正常构建”项目的指示灯为绿色
“构建和测试”项目的指示灯变为红色
被指责的开发商得到...

场景一：被指责的开发者一无所获。我们正在做 TDD，如果单元测试失败也没关系。 “构建和测试”项目是红色的，我们不打算将构建推送给 QA。

场景二：被指责的开发者被 TROLL，“构建和测试”项目永远不应该是红色的。

无论如何，我很想知道对这个过程的想法是什么？请保持简短。您的团队是否在构建中包含单元测试。如果是这样，您是否遵循 TDD？您是否总是努力通过测试来保持您的构建全部通过？

谢谢！

【问题讨论】：

拥有“Build [only]”有什么意义？如果测试失败，你的构建就毫无价值；没有必要假装什么东西是绿色的。
好吧，在此过程之前我们所做的是始终在将构建推送到 QA 之前运行测试。但正如你可以看到的那样，这显然不适合我们。

标签： build-process automated-tests tdd

【解决方案1】：

无论如何，我很想知道对这个过程有什么想法？请保持简短。你的团队是否在构建中包括单元测试。如果那么，你遵循 TDD 吗？你总是努力通过测试保持你的构建都过去了？

嗯，我们并不总是完全一致，但原则上：是的，是的。

第 1 点：

恕我直言，你真的必须在日常构建中运行你的测试。否则在你没想到的地方测试失败会暂时被忽视——这违背了单元测试的全部目的。只有在立即发现测试失败时才有用。

显然，在开发过程中，您会遇到破坏测试的阶段（例如重构）。但是这些应该尽可能短（最好是几分钟），并且您通常只在它们通过后才签入（就像您只在东西编译后签入一样）。如果您需要进行更广泛的返工，则需要一个私有分支:-)。

第 2 点：

关于测试中断时会发生什么：好吧，你修复它们（你，或任何破坏它们的人）。在一个好的团队中，严格的谴责应该是不必要的。但这确实是一个社会问题……

【讨论】：

【解决方案2】：

build 应该运行测试，总是通过，对于 TDD 来说是的

另外，如果您有自动化功能测试，也应该运行。通过功能测试，您可能无法通过所有测试，但是您永远不应该让正在通过的测试失败。

（即....您可以进行大量功能测试，以证明当前正在处理的事情正在做正确的事情，但在完成之前它不会通过。）

【讨论】：

作为旁注.....在实践中，我发现持续构建对于在同一个项目上工作的人来说不太有用，在提交之前，你得到，你测试，你签入。但是，对于您有许多项目使用通用库/框架的情况，那么它确实变得更加有用

【解决方案3】：

无论您是否使用 TDD，都不要签入，除非/直到它通过测试。或者，如果您愿意/必须，您可以将损坏的代码/测试签入到未声明测试的“私有”分支。

【讨论】：

是的，我就是这么想的。使用 Mercurial，我们可以提交代码但不能将其推出。我在想我们应该提交失败的测试，但在它们通过之前不要将它们推出。