开云体育

?

I don't think I've ever encountered exactly this point before. To the extent that it's true, I find it useless. :) Even so, I appreciate its attempt to be precise and to highlight the potential for confusion due to differences in understanding of terms.

I claim that practising TDD guides one to learn these things, because one can't _drive_ one's development using tests while ignoring what happens in the mind when you try. :) One thing that happens: one gets bored from typing the same thing over and over again and seeks a way to reduce the effort, which seems quite likely to at least encourage managing duplication somehow. If not, then what could possibly be happening during the "refactor" step?

A hypothetical programmer who is entirely unmoved by seeing duplication, who seems content literally to duplicate code all day long, is perhaps not refactoring, and therefore couldn't practise TDD.

This leads me, however, to wonder idly about what refactoring looks like if we use principles other than the Four Elements of Simple Design to inform our refactoring choices. I don't think I'm capable of imagining how that would actually happen, even though I can imagine that it's theoretically possible. I suppose someone who wanted to refactor, but didn't know those things, would be forced to find them, and therefore TDD would be the trigger for learning those things.