Updated TDD Mantra

If you have ever practiced test driven development (TDD), then you are probably familiar with the TDD mantra – red, green, refactor. I’m a big proponent of TDD, but I think the TDD mantra is missing a fourth step. 

Cecil Williams
Cecil Williams

Latest posts by Cecil Williams (see all)

In his book that introduced me to TDD, Test Driven Development: By Example, Kent Beck introduced the TDD mantra – red, green, refactor right away. In fact, you might have missed it, because it’s in the preface of the book. I think it’s a great mantra, because it represents the type of rhythm you can get into when doing TDD.

My favorite visual representation of the TDD mantra has been the red-green-refactor card created by Tim Ottinger for the Agile in a Flash blog:

red-green-refactor

However, as I stated at the top, I think the TDD mantra is missing a forth step. By design, TDD helps you create clean, simple code that only does what it needs to do. And that lends itself to the missing forth step: commit.

When you have competed the refactoring step, you are at a perfect point to commit. You have all your tests passing and you have introduced a small amount of change.

Making a commit at this point will improve your process even more. You will have autonomous chunks of work that are small and easy to understand. If you need to rollback or remove a change, it will be much easier to do because you have small independent commits to work with.

So I think the TDD mantra should include commit as the forth step:

updated TDD cycle

5 comments

  1. As a git user, I would say it should be red-green-commit-refactor-commit

    But I think having a workflow where you add commit is a good thing to have on the wall, thanks for the grapic!

  2. Bram raises an issue that I have frequently seen many past debates on. Some claim you should commit immediately after green-bar (as well as after refactoring). That makes things better for the committer, because they have fewer changes to reconcile/update with between commits.

    Others claim that committing after green-bar is actually too soon and makes things worse for the rest of the team, because you’re about to change the structure immediately afterward and commit code that is not yet clean/simple (and which we don’t want others in the team to depend upon just yet).

    What is your opinion??

  3. I personally prefer to do the commit after the refactoring. But if you are using a distributed version control system like Git, then it doesn’t matter because no one will see your commits until you push them (or submit a pull request). So commit as often as you like. You can always squash your commits before sharing your changes.

    However, if you are using a centralized version control system like Subversion, then I think you don’t want to commit until after the refactoring is complete. Otherwise you can cause pain for the rest of the team since your changes will be shared immediately.

Comments are closed.