In my view TDD requires three distinct skills to be "fully effective":
1. Writing the test first (as opposed to after)
2. Writing good tests (as opposed to crappy tests: You can write crappy tests first..)
3. Understanding design (this is where the initial test guides our design for the entry point in the unit of work, and the refactoring is us guiding the code into a more maintainable and readable internal design)
Teaching all three at the same time is hard. I've seen people try to just jump into TDD in places and failing because climbing this wall is too high in one go.
I've created courses separately for the design part and named them "refactoring skills for TDD" because even in a 5 days class, teaching the first two skills is difficult enough.
I'm not including here the skill of refactoring?LEGACY code into a testable state. I do teach that stuff, but there seems to be a distinction, at least to me between continuous refactoring during new code vs legacy (not tests) refactoring which is a much more dangerous state and might even require integration tests to begin. Perhaps we are really talking about 4 skills and not three.
On Mon, Nov 25, 2019 at 10:56 AM Brian Marick <marick@...> wrote:
> On Nov 23, 2019, at 12:32 PM, J. B. Rainsberger <jbrains762@...> wrote:
> I have noticed something when programmers try to practise TDD: they don't seem to learn how to refactor. I don't mean to state this so harshly, but it seems that they struggle a lot more with refactoring than I did when I started.
This seems really important. Do other people see the same thing?