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

问题描述

我们最近遇到了一些问题，开发人员向SVN提交代码，这些代码没有通过单元测试，无法在所有平台上编译，甚至无法在自己的平台上编译。虽然这是由我们的CI服务器（Cruise Control）取得的，我们已经制定了流程，以阻止它发生，我们真的希望能够阻止流氓提交发生在第一。 / p>

基于这里的一些其他问题，似乎是一个坏主意™，强制这是一个预提交钩子在服务器端，主要是由于长度构建+运行测试所需的时间。我做了一些Googling，发现这（所有开发人员使用TortoiseSVN）：

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

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

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


• 是否有更好的方法来做一般我想做的事情？

所有反馈。

解决方案

没有理由为什么你的预提交钩子不能运行单元测试！所有的预提交钩子必须是：

• 将代码签入工作目录


• 编译所有


• 运行所有单元测试


• 如果单元测试失败，则挂断。






这是完全可能的。





请记住，在一个预提交钩子中，整个钩子必须先完成才能允许提交





执行构建需要多长时间并通过单元测试？ 10分钟？想象一下，做一个提交，坐在那里等待你的承诺发生10分钟。





您的持续集成服务器是进行单元测试的绝佳场所。我更喜欢 Hudson 或 Jenkins 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?

I appreciate any and all feedback.

解决方案

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屋！