Great article. I'm working in a talk about Developer Flow and TDD and towards finding that elusive zen like state where the TDD you are practicing helps really drive out the design and strongly guides what to code next, and next and next. Specifically that TDD can be used to find this nice developer rythm.
Has anyone had this experience/success with this? What can help make the difference towards getting that nice flow out of TDD.
I'm inspired by Corey Haines and a bunch of code experiments he's illustrated over the years. One technique that struck me was that a nil return from a method was was an expected and desirable step during a TDD cycle and that guard clauses can be very helpful to driving out TDD designs while maintaining flow.
I'm looking for similar patterns for TDD decision making, especially those that help the dev stay in a good rythm.
Would love any ideas towards exploring this further.
Has anyone had this experience/success with this? What can help make the difference towards getting that nice flow out of TDD.
I'm inspired by Corey Haines and a bunch of code experiments he's illustrated over the years. One technique that struck me was that a nil return from a method was was an expected and desirable step during a TDD cycle and that guard clauses can be very helpful to driving out TDD designs while maintaining flow.
I'm looking for similar patterns for TDD decision making, especially those that help the dev stay in a good rythm.
Would love any ideas towards exploring this further.