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

问题描述

我们最近遇到了一些问题，开发人员向 SVN 提交的代码未通过单元测试，无法在所有平台上编译，甚至无法在自己的平台上编译.虽然这一切都由我们的 CI 服务器(巡航控制)接收，并且我们已经制定了流程来试图阻止它的发生，但我们真的希望能够从一开始就阻止流氓提交的发生.

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.

基于此处的其他一些问题，将其强制作为服务器端的预提交挂钩似乎是一个 Bad Idea™，主要是因为构建 + 运行测试所需的时间长度.我做了一些谷歌搜索，发现了这个(所有开发人员都使用 TortoiseSVN):

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

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

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:

• 有没有办法让 TortoiseSVN 中的预提交挂钩导致提交失败?
• 有没有更好的方法来做我想做的事情?

推荐答案

你的 pre-commit 钩子绝对没有理由不能运行单元测试！你所有的 pre-commit hook 所要做的就是:

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:

• 将代码签出到工作目录
• 编译所有内容
• 运行所有单元测试
• 如果单元测试失败，则钩子失败.

这是完全可以做到的.而且，在你的开发车间里，每个人都会讨厌你的胆量.

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.

构建和运行单元测试需要多长时间?10分钟?想象一下，做一个提交并坐在那里 10 分钟等待你的提交发生.这就是你被告知不要这样做的原因.

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.

您的持续集成服务器是进行单元测试的好地方.我更喜欢 Hudson 或 Jenkins 而不是 CruiseControl.它们更容易设置，并且它们的网页对用户更友好.更好的是，他们有各种可以提供帮助的插件.

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 有一些漂亮的图表可以向您展示单元测试的结果，因此您可以从网页上看到哪些测试通过和失败，因此非常清楚到底发生了什么.(CruiseControl 的网页对于普通人来说更难解析，所以这些东西并不那么明显).

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).

我最喜欢的 Hudson/Jenkins 插件之一是持续集成游戏.在这个插件中，用户会因良好的构建、修复单元测试和创建更多通过的单元测试而获得积分.他们会因为糟糕的构建和破坏单元测试而失去分数.有一个记分牌显示所有开发者的分数.

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.

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

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