I think that no one is suggesting to skip all testing. It’s example based testing that is problematic.
I’ll divert a bit now.
A necessary disclaimer. What follows is a rant and probably a borderline provocation. It might revive a long forgotten thread. If you have just eaten it’s better not to read it, because it might revive something else.
One of the things I’ve learned by using clojure is that it’s good to be opinionated. I also know that sometimes it’s better to keep your opinion to yourself. And what stands for you stands for me too - but I don’t want to divert so much as to talk about #metoo. It’s not that I don’t approve or anything … It’ll very soon be clear, if it’s not already, that it’s Anne Elk’s way of expressing the opinion that I admire, so I might as well state it. It’s Anne Elk’s way of stating the opinion or theory that I admire. With that out of the way I might as well say it. The opinion that is, it is mine and not Anne Elk’s.
When you spot a nonsense you say it’s a nonsense. Inevitably this involves a bit of finger pointing and it might hurt some feelings. It might even be well intended or elaborate nonsense but nonetheless a nonsense is still a nonsense - a nonsensical paraphrase of the Shakespeare. And here’s another - to write it or not to write it. That’s where my knowledge of Shakespeare ends, and it’s better to go back to the subject I don’t know either.
The TDD is nonsense. Actually, all xDDs are - that’s TDD and any of it’s siblings BDD, ATDD, and now also the newly coined RDD to name the few. It’s dangerous that TDD is regarded as best practice for development when it cannot be further away from any best practice.
There are so many D’s in xDD that at least one of them is bound to stand for danger. I believe they all do (even x - after all it is a driver). Saying that development is driven by x, seems like saying that x is the solution to making development easy. There are more points available for the one who can come up with x that’s really easy to do, because xDD boils down to do x and everything will be fine. It’s funny though that xDD originated in agile world which values “Individuals and interactions over processes and tools”.
Development is simple, two part process consisting of thinking (problem solving) and typing (code writing), where typing is always a consequence of thinking. Less thinking normally leads to more typing. Typing is easy, thinking is hard. The catch-22 of xDD is that the x that would make development easy has to be about thinking rather then typing, but making x about thinking makes xDD hard. When x is about typing xDD is easy but it drives typing, rather than development. By driving typing, more code than necessary is being written and therefore more bugs are introduced. So xDDs are BBD - buggy by design.
There’s an ever present urge to separate the thinking and typing part and in this sense agile is actually the new waterfall. In waterfall the thinking is done by a designated group of intellectually superior individuals not wanting to get their fingers dirty and full of various viruses by touching the keyboard, and therefore they rightly delegate typing to - as they call them - a bunch of easily replaceable overpaid underachievers not able to follow simple and clear instructions provided, always turning the what would be the next big thing to another lost opportunity, leaving us with only viable option of outsourcing the work to others the next time. In agile the thinking is done by no one because it hurts, for no one can really predict the future and we all actually start in the same boat on a calm sea until lo and behold totally unexpectedly for no reason at all, all hell breaks loose and the sea starts to behave unpredictably, sending waves towards us and what not and then we need to react quickly and swiftly if we are to survive because we never predicted the water to turn so badly and the boat to leak - I mean how could we? we don’t do prediction exactly because of the fact that water behaves so unpredictably - luckily we’re not on a river so it’s unlikely we’re heading towards waterfall.
I believe that thinking and typing has to be done by the same person, with at least some thinking ideally away from the keyboard. When you’re at the keyboard trying to write production ready code, you’re in execution mode. Without up-front thinking, that helped you form some kind of a plan, you simply cannot execute and it’s only by accident that you’ll end up with production ready code.
Obviously I’m not fond of TDD. I’m not even fond of RDD unless it’s intended use is to help developer to explore and/or learn about unknown territories by writing a throw away code. What I normally do though, is UTDD. It doesn’t stand for ultimate test driven development. Surprisingly it doesn’t even stand for up-front thinking driven development or even up-front thinking delegate downstream. It simply stands for up-front thinking and then don’t do.
The danger of TDD is that it leads to conversations about problems that are easily solvable when it would be better to have conversations about hard problems (like design, thinking, communication). And if there is already a generation of developers raised on TDD then sooner or later the hard problems will disappear until they are rediscovered and the new xDD is introduced.