如何保证所有单元测试都在提交之前通过？ [英] How can I guarantee all unit tests pass before committing?

问题描述

我们最近遇到了一些问题，开发人员将代码提交给SVN，这些代码无法通过单元测试，无法在所有平台上进行编译，甚至无法在自己的平台上进行编译。尽管这一切都由我们的CI服务器（巡航控制）处理，并且我们已经建立了流程来阻止它的发生，但我们真的很想能够阻止流氓提交的发生。

基于此处的其他一些问题，似乎由于其长度太长而强制将其作为服务器端的预提交挂钩是一个Bad Idea™建立+运行测试所需的时间。我做了一些Google搜索，发现了这一点（所有开发人员都使用TortoiseSVN）：

http://cf-bill.blogspot.com/2010/03/pre-commit-force-unit-tests-without.html

这至少可以解决两个问题（它不能在Unix上构建），但是如果失败，它不会拒绝提交。所以我的问题是：

• 有没有办法在TortoiseSVN中进行预提交钩子，导致提交失败？


• 是否有更好的方法来完成我通常想做的事情？

解决方案

绝对没有理由使您的预提交钩子无法运行单元测试！您所有的预提交钩子都需要做的是：

• 将代码检出到工作目录中


• 编译所有内容


• 运行所有单元测试


• 然后，如果单元测试失败，则挂接失败。

这是完全可能的。而且，事后，开发商店中的每个人都会讨厌您的胆量。

请记住，在预提交挂钩中，必须先完成整个挂钩，然后才能允许提交发生 并且控制权可以返回给用户 。

进行构建需要多长时间并通过单元测试？ 10分钟？想象一下进行一次提交并坐在那里10分钟，等待您的提交发生。 这就是为什么不告诉您这样做的原因。

您的持续集成服务器是进行单元测试的好地方。与CruiseControl相比，我更喜欢 Hudson 或 Jenkins 。它们更易于设置，并且网页更加用户友好。甚至更好的是，他们拥有各种可以提供帮助的插件。

开发人员不希望知道他们破坏了构建。想象一下，如果您组中的每个人都收到一封电子邮件，指出您犯了错误的代码。在提交代码之前，您不确定代码是否正确吗？从网页上查看哪些测试通过和失败，所以很清楚发生了什么。 （CruiseControl的网页对于一般人来说很难解析，因此这些东西并不明显）。

我最喜欢的Hudson / Jenkins插件之一是持续集成游戏。在此插件中，为用户提供了良好的构建，修复单元测试以及创建更多通过的单元测试的分数。他们因糟糕的构造和破坏单元测试而失去分数。有一个计分板显示所有开发人员的得分。

我很惊讶开发人员对它的认真对待。一旦他们意识到自己的CI游戏成绩是公开的，他们就变得非常有竞争力。当构建服务器本身由于某种奇怪的原因而失败时，他们会抱怨，并且由于糟糕的构建而失去10分。但是，失败的单元测试的数量下降，下降，并且编写的单元测试的数量猛增。

We've had problems recently where developers commit code to SVN that doesn't pass unit tests, fails to compile on all platforms, or even fails to compile on their own platform. While this is all picked up by our CI server (Cruise Control), and we've instituted processes to try to stop it from happening, we'd really like to be able to stop the rogue commits from happening in the first place.

Based on a few other questions around here, it seems to be a Bad Idea™ to force this as a pre-commit hook on the server side mostly due to the length of time required to build + run the tests. I did some Googling and found this (all devs use TortoiseSVN):

http://cf-bill.blogspot.com/2010/03/pre-commit-force-unit-tests-without.html

Which would solve at least two of the problems (it wouldn't build on Unix), but it doesn't reject the commit if it fails. So my questions:

• Is there a way to make a pre-commit hook in TortoiseSVN cause the commit to fail?
• Is there a better way to do what I'm trying to do in general?

解决方案

There is absolutely no reason why your pre-commit hook can't run the Unit tests! All your pre-commit hook has to do is:

• Checkout the code to a working directory
• Compile everything
• Run all the unit tests
• Then fail the hook if the unit tests fail.

It's completely possible to do. And, afterwords, everyone in your development shop will hate your guts.

Remember that in a pre-commit hook, the entire hook has to complete before it can allow the commit to take place and control can be returned to the user.

How long does it take to do a build and run through the unit tests? 10 minutes? Imagine doing a commit and sitting there for 10 minutes waiting for your commit to take place. That's the reason why you're told not to do it.

Your continuous integration server is a great place to do your unit testing. I prefer Hudson or Jenkins over CruiseControl. They're easier to setup, and their webpage are more user friendly. Even better they have a variety of plugins that can help.

Developers don't like it to be known that they broke the build. Imagine if everyone in your group got an email stating you committed bad code. Wouldn't you make sure your code was good before you committed it?

Hudson/Jenkins have some nice graphs that show you the results of the unit testing, so you can see from the webpage what tests passed and failed, so it's very clear exactly what happened. (CruiseControl's webpage is harder for the average eye to parse, so these things aren't as obvious).

One of my favorite Hudson/Jenkins plugin is the Continuous Integration Game. In this plugin, users are given points for good builds, fixing unit tests, and creating more passed unit tests. They lose points for bad builds and breaking unit tests. There's a scoreboard that shows all the developer's points.

I was surprised how seriously developers took to it. Once they realized that their CI game scores were public, they became very competitive. They would complain when the build server itself failed for some odd reason, and they lost 10 points for a bad build. However, the number of failed unit tests dropped way, way down, and the number of unit tests that were written soared.

这篇关于如何保证所有单元测试都在提交之前通过？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！