Following the RGR cycle
We saw in the previous chapter 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 is inside and outside that boundary. The public methods form the outside of our object. The Arrange, Act and Assert rhythm helps us design those.
We’re using the word rhythm here in an almost musical sense. It’s a constant, repeating theme that holds our work together. There is 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 will be different, but the rhythm of work is the same, as though it were a steady beat in an ever-changing song.
Once we have written...
