I love to try new programming tools and techniques. Especially if they involve TDD, unit testing, or something related. A few months ago I learned about "test && commit || revert" and it instantly looked like fun to me.
"test && commit || revert" (or just "TCR") was originally invented during a Code Camp in Oslo by Lars Barlindhaug, Oddmund Strømme, Ole Johannessen and Kent Beck.
Kent Beck wrote about this in this blog post.
The main idea
The main idea comes from Kent Beck's "Limbo Story". It's all about making changes as small as possible so that they can be easily shared and merged. But how do you enforce small changes?
TCR works best if you have some kind of file watcher or any other trigger that will start the TCR process immediately "on save".
So every time you make a change (and save your files), the test will be run. If all your tests pass, the code will be committed to source control. So every state of your code that is successfully validated by the tests is committed. But here comes the interesting part: If the tests don't pass, your changes will be reverted. Sound scary, doesn't it?
In fact, it is not that scary if you think about it. Every little change you make will be committed separately. So you will just lose a small amount of work.
Show me the code
Well "code" is a big word here. But let's look at the command that is used. I am a .NET developer, so I use dotnet test to run my tests. But you can replace that part with whatever works for your stack.
dotnet test && git commit -am working || git reset --hard
It's really that easy.
"But my git log..." 😨
Sometimes, when I talk to other developers about TCR, their reaction is something like this:
Are you serious? Have you thought about the git log? It will just say "working" all the time. That's not helpful at all.
That's true. I don't think using "working" as a message for every commit is not super helpful. But I think it is not a big deal as well. When you are done with a specific part of your feature/bugfix, just squash your commits before you push your changes. Problem solved.
My experience with TCR
I have tried TCR using some katas and also on a few small side projects. I think it is fun. It forces you to make small steps which is a good practice in general.
But it comes with some extra costs as well. As mentioned in the last paragraph, you don't want to push your "working" commits, do you? That means you have to squash your commits manually all the time. Of course, it is not a big deal, but it's an extra step.
Also, I'm a big fan of TDD. And to be honest, I really miss the "watch it fail" phase when doing TCR. If you run the TCR process on every "save" event, you cannot watch your new test fail, because that will revert your last change (which was the creation of the test).
Final thoughts
I don't think you have to use TCR all the time and everywhere. But it is fun to try it. And you will learn to take super small steps. Again, you don't have to make these tiny-tiny steps all the time, but I think you should have the ability to do so. It might come in handy someday.
More resources on TCR
There are a lot of cool resources on TCR.
- If you like podcasts, you should check out the "TCR" episode of "Hanselminutes" by Scott Hanselman
- The SoCraTes UK community has a couple of TCR session available on YouTube
- The awesome Kent Beck has a cool TCR introduction on YouTube as well
Top comments (0)