A few years ago, I did an experiment where I completed the first few Advent of Code puzzles using TCR, or “Test, Commit, Revert”. It was a fun experiment, and I documented what I learned, but I never intended to adopt TCR for my day-to-day work. Recently, I’ve started doing something akin to TCR when working on my website. I’m doing TC without the R.

When I set up my site, I configured GitHub Actions the way I do on most projects; my workflow linted the code, ran the tests, and, if everything passed, deployed the site.

But I was always running the tests locally anyway, so running tests again was redundant and a waste of computing power. I’m the only one working on this project. Why not just have my git hooks do everything?

I removed all the steps from my Actions workflows except for the deploy step and configured my git hooks to (on top of the linting and autoformatting they already did) run my tests, blocking the commit if they fail.

Quickly I found myself making changes and immediately attempting to commit without running any tests. git commit -a became my test runner. If the tests passed, then they were committed.

For this to be viable, you need a fast test suite. From working on Rails apps, I’m used to test suites that aren’t fast enough for this. Most non-trivial Rails applications have test suites that take far too long to run locally whenever you want to commit. It works great for this app, where the test suite is small and the tests are very fast.

TCR is a unique technique that can push you towards making the smallest possible changes. It’s impractical for regular work, but an interesting constraint that will change how you look at your work, in the same way that using a tool like Gerrit can be quite painful but also push you to become a better developer.

If you’re working on a small personal project where you write tests, consider simplifying your workflow by making git your test runner. It might change how you look at the changes you’re making.