Red-Green or Refactoring First?
Which came first, the chicken or the egg? The Refactor or the Failing test?
Originally published on . Last updated on .
When it comes to Test-Driven Development, we often see it as a cycle consisting of three parts: RED, GREEN, and REFACTOR.
I think about the process as two high-level activities:
Changing the behavior of the system via coded expectations: this is the RED-GREEN part of the cycle. We do this for “them”, i.e., the folks who asked us to solve their problem (or perhaps implement their solution) and make their lives better (we hope).
Preserving the behavior and making the code easier to understand. Can also be adapting it to the next thing we’re about to implement, i.e., the REFACTOR part. We do this for us, the humans working with the code, to make our lives better; to increase the changeability of the system.
However, we don’t always need to start with a change in behavior (i.e., step 1), sometimes we start with making the code easier to work with via REFACTOR, which looks like this:
TDD is a cycle, after all, with a choice of where to begin. Though I treat each time we land in GREEN and REFACTOR as safe stopping points (where I’ll try to commit to version control). This is related to “Small Steps” and “Ready Points” (GeePaw Hill), which I’ll talk more about in a future essay.
Over the next several articles I’ll dive deeper into these two parts: Change Behavior (the RED-GREEN part) and Increase Changeability (the REFACTOR part).