Live data from Hacker News

Setting up pre-commit tests with Git

dduvnjak.pw

1–10 of 12 posts

Re: Setting up pre-commit tests with Git

#2
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.

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.

You need CI anyway, so I'd leave tests there, and let the developer decide when to run the unit tests on his machine.

Re: Setting up pre-commit tests with Git

#3
I can see this working if you're collaborating without Github's pull requests.

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.

Re: Setting up pre-commit tests with Git

#4
post #2

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. 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 wo…

This example runs unit tests only, so it doesn't take too long (integration and other tests would still have to be executed on CI). It's more of a convenience than a practice, so you basically don't have to think about running unit tests.

Re: Setting up pre-commit tests with Git

#5
post #4
post #2

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. 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 wo…

This example runs unit tests only, so it doesn't take too long (integration and other tests would still have to be executed on CI). It's more of a convenience than a practice, so you basically don't have to think about running unit tests.

Sure, if you find it convenient - go for it. However, I'd not enforce it as a policy for whole organisation for the reasons outlined above.

Re: Setting up pre-commit tests with Git

#6
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.

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.

Re: Setting up pre-commit tests with Git

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

Re: Setting up pre-commit tests with Git

#8
post #6

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

You could always set the script to only run the tests on certain branches on pre-commit. (i.e. if branch name is not master, exit 0)

Re: Setting up pre-commit tests with Git

#9
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.

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.

Post reply on HN