你如何定制你的开发过程，为构建添加单元测试？

我已经遇到了工作中的情况，有人建议将我们的单元测试添加到Cruise Control连续构建过程中。该单元测试将被添加为CC另一个项目，这样我们将有一个“中等身材”项目和“构建和测试”项目。我们目前使用“Normal Build”过程来a）确保没有开发人员破坏构建，并且b）确保在发布即将推送到QA/Production时构建不会中断。你如何定制你的开发过程，为构建添加单元测试？

通过向流程添加单元测试，我们可以：a）当单元测试已被破坏时通知我们将检查以确保它不是我们编写的单元测试; b）确保没有单元失败构建会发布到QA/Production。所以我明白好处，但我仍然担心这会如何影响我们的开发过程。这里的情景就是我看到发生......

当前进程...

构建服务器建立巡航控制 “中等身材”项目
指示灯亮起红色（巡航控制）当构建失败
归咎于开发商得到了巨魔

新工艺..。

另一个CC项目的“构建和测试”（现在的两个项目）添加
灯是绿色的“普通身材”项目
指示灯亮起红色的“构建和测试”项目
被谴责的开发者得到...

方案一：被指责的开发人员没什么。我们正在做TDD，如果单元测试失败，那也没关系。 “构建和测试”项目是红色的，我们不打算将构建推送到QA。

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

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

谢谢！

来源

2010-09-23 matt_dev

完全依靠“构建[only]”有什么意义？如果测试失败，你的构建是毫无价值的。假装没有任何东西是绿色的。 – Draemon 2010-09-23 22:06:02

那么，在我们将构建推送到QA之前，我们在这个过程之前所做的就是始终运行测试。但正如你所知道的那样，显然不适合我们。 – 2010-09-23 23:08:19

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

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

点1：

恕我直言，你真的必须在的每日构建运行测试。否则，在你没有预料到的地方测试失败会在一段时间内被忽视 - 这打破了单元测试的全部目的。如果发现测试失败，立即。

很明显，在开发过程中会出现一些阶段，例如重构测试（例如重构）。但是这些应该尽可能短（分钟，理想情况下），而且通常只有在他们通过时才进行检查（就像你一次只编译一次就检查一样）。如果您需要进行更广泛的返工，您需要一个私人分支:-)。

点2：

至于何时测试突破会发生什么：嗯，你解决这些问题（你，或谁折断了）。在一个优秀的团队中严格谴责应该是不必要的。但这确实是一个社会问题...

来源

2010-09-23 22:02:48 sleske

构建应该运行测试，总是传球，并且是对于TDD

还，如果你有自动化功能测试，应该也运行。通过功能测试你可能没有通过所有的测试，但是你永远不应该开始失败通过的测试。

（ie ....你可以进行一系列功能测试，证明目前正在进行的工作正在做正确的事情，但在完成之前它不会通过。）

来源

2010-09-23 22:01:10

作为一个侧面说明.....在实践中，我发现连续构建对于在同一个项目中工作的人员来说并不是太有用，在提交之前，你会得到，测试，检入。但是，对于你有使用通用库/框架的项目数量，那么它确实变得非常有用 – 2010-09-23 22:25:26

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

来源

2010-09-23 22:06:07 ChrisW

是的，这就是我的想法。使用Mercurial我们可以提交代码但不会推出。我认为我们应该进行失败的测试，但不要推迟他们，直到他们通过。 – 2010-09-23 23:06:12

你如何定制你的开发过程，为构建添加单元测试？

回答

相关问题