A reader asked me this question:
I’ve always wondered how does the basic flow of red, green, refactor reconcile with the concept of “make the change easy, then make the easy change”? Does that imply sometimes doing an extra refactoring before the next red [failing test] after deciding what the next change should be or is “make the change easy” referring to non-TDD things like an occasional larger-scale refactoring task?
This is a companion discussion topic for the original entry at https://blog.thecodewhisperer.com/permalink/a-natural-microflow-in-tdd