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