I'm not sure if this is a good practice. As project grows, running tests takes more time - remember that tests are not only unit tests which should run quickly, there are acceptance tests which can take some time to run. Waiting for commit to finish can become painfully slow.<p>Additionally, I like to commit partial solutions to feature branch as I work. Later I will fix the mess with rebase - this workflow wouldn't work.<p>You need CI anyway, so I'd leave tests there, and let the developer decide when to run the unit tests on his machine.
IMO we shouldn't have to jump through hoops to be able to commit. Let people commit whatever they want and then run tests to decide if you want to merge in their branches.<p>The workflow should encourage people to commit early and often to safeguard the work they've been doing as much as possible. It's very frustrating to lose work because it wasn't in the git object store.
Wouldn't it be a lot better choice to make this a post-receive hook on your Git server? E.g. run the tests before code gets accepted to master.<p>I often intentionally commit code that doesn't work (pass tests or even compile), but not to master branch. One of the big advantages of Git is that you can share code with your team mates even if that code doesn't work yet.
At my work I setup a pre-commit hook that my team uses to run Uncrustify, a source-code beautifier. If the style of the commit doesn't match our rules for that language it will spit out a command for you to run to fix it. I think overall it has been a big win for our team. Uncrustify runs almost instantly and having a uniformly styled code-base is worth the small inconvenience.
I can see this working if you're collaborating without Github's pull requests.<p>Personally I'd want to scope it to only run the test suite for merge commits onto the master branch since it's reasonable in development branches to commit changes with failing tests.
Warning, this won't check the code you're committing, it'll check the code you have in your working directory. You need to stash all non staged changes before running the tests.