我遇到了一个工作环境，建议将我们的单元测试添加到Cruise Control连续构建过程中。单元测试将作为CC中的另一个项目添加，以便我们有一个 “Normal Build” 项目和一个 “构建和测试” 项目。我们目前使用“正常构建”过程来a）确保没有开发人员破坏了构建，并且b）确保在将版本推送到QA / Production时不会破坏构建。
通过向流程中添加单元测试，我们可以a）在单元测试被破坏时得到通知，因此我们将检查以确保它不是我们编写的那个，并且b）确保在单元测试之前没有单元失败build被发布到QA / Production。 所以我理解其中的好处，但我仍然担心这将如何影响我们的开发过程。这是我看到的场景......
当前流程......
新流程.. 。
场景一：责备开发者得到了什么。我们正在进行TDD，如果单元测试失败就可以了。 “构建和测试”项目是红色的，我们不打算将构建推向QA。
场景二：Blamed开发者获得TROLL，“构建和测试”项目永远不应该是红色。
无论如何，我很想知道这个过程的想法是什么？请保持简短。您的团队是否在构建中包含单元测试。如果是这样，你会关注TDD吗？你总是努力保持你的构建与测试一样过去吗？
谢谢！
答案 0 :(得分：1)
构建应该运行测试，总是传递，并且对于TDD是
另外，如果你有自动功能测试，那也应该运行。通过功能测试，您可能没有通过所有测试，但是您永远不应该开始失败 传递的测试。
（即......你可以进行一系列功能测试，证明当前正在处理的东西正在做正确的事情，但直到完成它才会通过。）
答案 1 :(得分：1)
无论如何，我很好奇地阅读了什么 关于这个过程的想法？请 保持简短。你的团队吗？ 包括构建中的单元测试。如果 所以，你是否关注TDD？你总是这样吗？ 努力使您的构建与测试保持一致 一切都过去了？
嗯，我们并不总是完全理解它，但原则上：是的，是的。
第1点：
恕我直言，你真的必须在日常构建中运行你的测试。否则，在您不期望它们的地方进行测试失败将暂时不被注意 - 这会破坏单元测试的整个目的。只有在立即 注意到测试失败时才有用。
显然，在开发过程中会出现中断测试的阶段（例如重构）。但是这些应该尽可能短（理想情况下是几分钟），并且通常只有在它们通过后才会签入（就像你只在一次编译时检入一样）。如果你需要做更广泛的返工，你需要一个私人分支： - ）。
第2点：
关于测试中断时会发生什么：嗯，你修复它们（你或者那些破坏它们的人）。在一个优秀的团队中，严格的谴责应该是不必要的。但这确实是一个社会问题......
答案 2 :(得分：1)
您是否使用TDD，除非/直到通过测试，否则不要签入。或者如果您喜欢/必须，您可以将损坏的代码/测试签入到未确认测试的“私有”分支。