What parts of TDD have I forgotten?

What patterns are there when TDDing?

How closely will the lessons here link to those from Clean Code?

What will I learn to allow me to use TDD more effectively?

What stood out for me throughout the examples presented in this book was Kent Beck’s approach to keeping the green bar. Suggestions such as always beingone change away from a green bar and implementing code in whatever way makes us reach the green bar faster before refactoring it were new to me. I am often guilty of trying to make too many changes at once so this was a good reminder to take small steps and keep the tests running frequently.

Kent described the purpose of TDD as "closing the gap between decision and feedback". At a high level this is in fact what it’s all about and is something I forget when I’m deeply entrenched in the code. Getting faster feedback is certainly an important thing to aim for when using TDD.

One of the things which surprised me about this book was that the pattern being followed to make tests pass involved first of all writing code that was not perfect but which passed the test. Uncle Bob pointed out this same approach in Clean Code - write dirty code than clean it. While I think this approach certainly makes sense in theory, I think in practice it requires great discipline (especially when time pressures are involved) to go back and clean up the code every time. Perhaps there is some balance to be found between making the tests pass and writing a reasonably good solution first time around.

Another interesting approach recommended was to write initial tests which are concerned with implementation and then refactor those into ones which test externally visible behaviour. I have certainly been maybe over dogmatic in wanting to only write tests for behaviour of classes, which often makes it difficult to actually get started. This approach could certainly be useful as one to just get something running.

The Green Bar Patterns were new to me - these describe ways to get a test to pass. Kent lists three of them:

Kent keeps a to-do list throughout the examples - he often speaks of avoiding distraction from the current test by simply adding new tests or ideas onto the list and looking at them after the current task is complete. I sometimes find myself going off and trying new ideas before finishing the current one so hopefully using this approach will allow me to remain more focused.

Another thing I often wonder with TDD is how big our steps should be - Kent describes TDD as 'a steering process - a little this way, a little that way. there is no right size'. To paraphrase - steps of different sizes can be used and we should vary these depending on the situation. If the steps feel too small, make them bigger, and if they feel too big, make them smaller.