Pre-Commit hooks for running tests

In my current engagement, there’s been more than a single call to make running your test-suites as a step in a pre-commit hook.

I believe this is a bad idea, and these are my reasons.

Not running tests before committing is a discipline problem

Trying to solve a discipline problem with tooling is a bad idea.

For instance, as a developer, I would not require a code-coverage tool to tell me that I have missed writing a test. As a TDD practitioner (and a strong advocate for it), the tool is unnecessary.

As such, if your team follows Trunk-Based Development as a standard practice (which I will again recommend, if your team is ready for it); it becomes basic developer discipline to ensure that you don’t break the build, i.e, you are diligent enough to run tests before checking in your code.

Any tool introduced for ensuring you do this, seems to be a step in the direction of baby-sitting.

The entire test-suite might not need to be run for every commit

Sometimes when I work on a certain area in a code-base, I make a conscious and deliberate decision to run unit-tests / integration tests pertaining to that area in the code-base.

This is a very deliberate move, aiding me to make faster, quicker commits to the mainline.

A pre-commit/push hooks stops developers from having such a workflow.

It really doesn’t stop you skipping the steps anyway

When developers see that running the entire suite of tests is taking time, they might even choose to ignore it by pushing with the

git commit --no-verify (or)
git push --no-verify 

option. Some might even modify their git aliases to have these options passed in.

And then we’re back to the same problem we had — developers “forget” to run the tests. We’re back to square one now.

For these reason, I’m not a big fan of introducing pre-commit and pre-push hooks into your code-bases, because, they are often a band-aid solution. And I thoroughly dislike band-aid solutions.