Following the Red-Green-Refactor Cycle

We know how a single unit test is split into three parts, known as the Arrange, Act, and Assert sections. This forms a simple rhythm of work that guides us through writing every test. It forces us to design how our code is going to be used—the outside of our code. If we think of an object as being an encapsulation boundary, it makes sense to talk about what’s inside and outside that boundary. The public methods form the outside of our object. The Arrange, Act, and Assert rhythm helps us design those.

RGR rhythm

We’re using the word rhythm here in an almost musical sense. It’s a constant, repeating theme that holds our work together. There’s a regular flow of work in writing tests, writing code, improving that code, and then deciding which test to write next. Every test and piece of code is different, but the rhythm of work is the same, as though it were a steady beat in an ever-changing song. Once we’ve written our test, we turn to creating the code that is inside our object—the private fields and methods. For this, we make use of another rhythm called RGR.