How Practicing TCR (Test && Commit

InfoQ Homepage Articles How Practicing TCR (Test && Commit || Revert) Reduces Batch Size

Feb 20, 2023 13 min read

by

Philippe Bourgau

reviewed by

Matt Campbell

A while ago, a colleague and I ran a code kata at a conference in Paris. Here were the kinds of learnings that the people expressed at the end:

I thought I was doing small steps, but I discovered I could make them even smaller!

I still need more experience with the TDD itself!

ScyllaDB is the database for data-intensive apps requiring high throughput + low latency. Achieve extreme scale with the lowest TCO. Learn More.

I got lost in endless refactoring.

By now, DevOps and Continuous Delivery are widespread in the industry. But, is work done in small slices, continuously integrated, and played with? Many teams still work with feature branches, integrating only full features!

Wouldn’t it be great if writing code in baby steps had become second nature to developers? Achieving the full potential of Trunk-Based development, DevOps, and Continuous Delivery!

TCR is a technique that forces you to write code in baby steps! It’s also a harsh but effective teacher. Let’s learn more about it. We’ll see how developers are using it to do more continuous delivery and to coach their teammates:

TCR stands for Test and Commit or Revert. It replaces the test command with a test && commit || revert command. So, developers will run the TCR command instead of launching test to check their code is working. If the code works as expected, TCR commits it to the version control system. If the code does not work, TCR reverts it to its latest working state!

TCR started as a crazy experiment by Lars Barlindhaug, Oddmund Strømme, Ole Johannessen, and Kent Beck during a Code Camp in Oslo. Kent Beck then spread the word through his blog. Kent Beck claims we should try stupid ideas because sometimes, they turn out to be brilliant! Whether TCR is stupid or brilliant is still an open question. Yet people who stick with it long enough find it illuminating!

source

You’re bound to learn something. (Kent Beck about trying TCR)

Indeed, developers who gave TCR a serious try report many benefits:

Let’s read what they say firsthand. Here are interviews with two TCR practitioners.

Hi Guillaume, can you tell us about yourself in a few words?

Guillaume Faas: Sure. My name’s Guillaume, and I’m currently a .NET Developer Advocate at Vonage. I’ve been in the Software industry for almost 15 years, in the .NET ecosystem all the way through. However, if I had to pick one milestone from my career, it wouldn’t be a role or a project but the acknowledgment of Software Craftsmanship. Indeed, it drastically changed my view on software development, and there’s a before and an after. Since then, I consistently try to spread the mindset and its values.

Can you share your TCR story: how you got into TCR? What were your first impressions?

Faas: Funny thing that you ask. My first encounter with TCR was during one of your workshops, specifically, the Bowling game in the Software Craftsmanship Luxembourg meetup. I remember the workshop being so much fun and enlightening. But unfortunately, our baby steps were not so small, and we started to fear saving our changes. Nevertheless, I came out of it excited with the will to practice more.

Today, what do you use TCR for?

Faas: To be fully transparent, I apply TCR through the tool the Murex tech coaching team built. I mainly use it for katas during coaching sessions. It’s a great way to teach TDD because it brings more ideas and is not necessarily harder. I also used it on production code, but I’d advise people to be careful. Verifying that every test passes every single time can drastically slow down your feedback loop. Finally, I also used it during technical tests as a candidate.

What benefits have you noticed from using TCR in the training context?

Faas: People realize they do not trust the code they write. As I said before, we feared saving our changes. There’s a clear connection with the following quote from Kent Beck: “Test-driven development is a way of managing fear during programming.” Also, we all think we’re working in small increments. Spoiler: we’re all wrong. TCR forces you to go small and often, bringing many benefits, including a sustainable pace and less tiring work.

How do people typically react when confronted with TCR during training?

Faas: “Oh no, I’m going to lose my code.” And it might be right. But people quickly realize they will only lose a little if they reduce their TDD cycles. It also becomes quite addictive and fun. You’re encouraged to challenge your confidence in the code you just wrote. I’ve observed the following every single time: people started to bet on the test output before running the tests.

What challenges did you face, or are you still facing, when using TCR for training?

Faas: People are usually intimidated. They believe they need to learn another thing simultaneously, which is wrong. Also, reverting code feels like a waste of productivity. So the challenge is to make them try anyway.

Have you any recommendations for readers who want to use TCR to practice or train others?

Faas: Kent Beck’s blog post on the topic itself is an excellent way to start. Also, being a consistent reader, I can only recommend your blog. It contains fantastic articles like, for example, the one on evolutionary design. Otherwise, practice makes perfect. So join some people for kata and experiment. It’s fun, and you’re guaranteed to learn something.

Where do you see TCR in the future of software engineering?

Faas: That’s a tough one. I advocate TDD and TCR as much as I can. Although TCR is pretty recent (2018, if I recall), TDD goes back to the early 90s and still needs to be widely adopted. Most of the developers I encounter still never wrote a test or, worse, are allergic to tests! We may have several years of hustle before TCR becomes a thing. As practitioners, we must spread the word and accelerate its adoption.

According to you, what should we do to bring TCR one step closer to that vision?

Faas: I have to go back to the previous question. We all know TDD is a beautiful practice, and most thought leaders agree. But where did it fail? How is it not more adopted, given the number of talks, books, and articles praising its benefits? How do we guarantee a different outcome? I don’t have a magical solution. We must bring awareness on the matter, one mob at a time.

Hi Xavier, can you tell us about yourself in a few words?

Xavier Detant: I am currently CTO at Great Place To Work France and will soon be joining Eove. I worked for ten years as a contractor before becoming employed full-time at a software company. I discovered TDD and adopted it 8 or 9 years ago. I am the father of a very cute boy and the husband of a lovely wife.

Can you share your TCR story: how you got into TCR? What were your first impressions?

Detant: I discovered TCR, like many, through Kent Beck’s blog post. My first thought was, “that sound like an interesting constraint for a kata,” so I tried it. At first, it reminded me of the “your computer has a defect” constraint where a script on the background resets your code through git every two minutes, and you can only commit when it’s green. The main difference being the script is your test, and the loop is as long or as short as you want. My first reaction was, “I love it for refactoring but not seeing any test going to red is very uncomfortable.” I was curious if the discomfort would stick, so I did more katas. Doing so, I really enjoyed that:

I really disliked the following:

Because of that, I adapted the flow of TCR to be closer to TDD but stuck to the stuff I liked from TCR. The symmetric of TCR is TRC: run the tests; if green, revert; otherwise, commit. That’s a very good fit for the red phase of TDD. So I created a script to do that (and simplify some complexities like avoiding red commits when you push). I liked the result and have been using it since.

What do you use TCR for?

Detant: I use it for everything I code. It completes my TDD workflow.

What benefits have you noticed from using TCR in your day-to-day work?

Detant: An individual benefit is feedback on your fatigue state. If you are too tired to make a good move, you get literally stuck. And you see the size of your steps shrinking during the day. So you are conscious of it at any time while still going as fast as you actually can.

What are the impacts of using TCR on the software construction process?

Detant: An organizational benefit is improved continuous integration and delivery. At any time, anyone with access to the pre-production platform can see what I have done on my task and give feedback. It made a big step forward in agility as we can draft something, start using it at the same time, and improve according to the first impression. That also means no hard feelings:

That’s super comfortable, relaxed, and constructive.

What challenges did you face, or are you still facing, when using TCR in production work?

Detant: The main challenge is not to “cheat.” In your IDE, you are just a CTRL+Z away from getting back the code you just lost (Note: just after TCR reverted). If you lost it, there’s a reason. Stop and think about it! Of course, pragmatism is key. If you saw a typo at the same time as you ran your tests, allow yourself to cheat. Yes, I still face it, especially at the end of the day, when I don’t want to admit that I am too tired to do quality work and want to finish what I am doing. Every time I cheated for that reason, I regretted it the next day.

Have you got any recommendations for readers who want to start using TCR?

Detant: Try TCR for the refactoring phase only at first. Then, discover with katas and start using it on production code. Finally, if you like it, find a way to expand it outside of the refactoring steps.

Where do you see TCR in the future of software engineering?

Detant: I don’t think TCR will go as far as TDD did (and TDD is still not ubiquitous). I think it will be a very good starting point for new ideas of working, though. Sadly, as for TDD, we’ll probably need to wait 20 years to see different ways of working becoming “mainstream.”

According to you, what should we do to bring TCR one step closer to that vision?

Detant: Try ideas. We won’t improve our way of working if we don’t try things—even the “obviously stupid” ones. We have the luxury of being able to create side projects for fun. We are allowed to fail at our side projects for silly reasons. Let’s leverage that. Heck, most projects can afford to fail for silly reasons since so many projects still fail for “non-silly” reasons like:

If a product is not life-critical, using new, untested ways of working is an option. Take risks! Our field is new, and we have much to discover, test, and learn. Be an explorer and share your adventures with us!

My colleagues and I have been practicing TCR too, and we observed more benefits!

TDD, followed by the book, results in high coverage by design. By enforcing a strict TDD, TCR yields even higher coverage! TCR leads to 90% or more solid branch coverage. The remaining uncovered code is constants or glue code.

Increased coverage is another way TCR improves continuous integration and delivery flow. By catching errors up-front, developer tests avoid failures in the downstream pipeline.

Git handover is a straightforward, robust, effective, and cheap way of doing remote pairing. It works by:

By continuously committing small code changes, TCR makes git-handover seamless. It’s easy to tweak your TCR script to push when it commits. We can automate pulling the latest changes too. Role-switching in the mob becomes as simple as starting screen sharing!

TDD is difficult to teach because applying it in ‘hairy’ production code is tricky for newbies. Surprisingly, it’s easier for people to buy in TCR! TCR seems crazy, and people don’t even think of using it in their day-to-day work. As trainers, we explain that it’s a tool to help them practice baby-steps programming. They get in a constructive ‘training’ mindset. Later, back at their desks, they can split their work into smaller steps, even in legacy and untested codebases!

Guillaume and Xavier said that the best way to get started with TCR is to try it on a kata! Just run git init and use a different command for your tests:

<your test command> && git commit -am "TCR" || git restore.

If you want a bit more bells and whistles, there are plenty of open-source tools for TCR:

Get used to TCR on a few katas! Then, once you get the knack for it, if you have fast enough tests on your production code, give it a try on pure refactoring!

Writing for InfoQ has opened many doors and increased career opportunities for me. I was able to deeply engage with experts and thought leaders to learn more about the topics I covered. And I can also disseminate my learnings to the wider tech community and understand how the technologies are used in the real world.

I discovered InfoQ’s contributor program earlier this year and have enjoyed it since then! In addition to providing me with a platform to share learning with a global community of software developers, InfoQ’s peer-to-peer review system has significantly improved my writing. If you’re searching for a place to share your software expertise, start contributing to InfoQ.

I started writing news for the InfoQ .NET queue as a way of keeping up to date with technology, but I got so much more out of it. I met knowledgeable people, got global visibility, and improved my writing skills.

Becoming an editor for InfoQ was one of the best decisions of my career. It has challenged me and helped me grow in so many ways. We'd love to have more people join our team.

InfoQ seeks a full-time Editor-in-Chief to join C4Media's international, always remote team. Join us to cover the most innovative technologies of our time, collaborate with the world's brightest software practitioners, and help more than 1.6 million dev teams adopt new technologies and practices that push the boundaries of what software and teams can deliver!

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example

We protect your privacy.

You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p