This is exactly what I'm getting at in the blog post. I think the message that it works "if you listen" needs to be front and center so that learners and skeptics can figure out how to apply TDD in scenarios where they don't have any hands on guidance.
It's very common for TDD advocates to claim that testable code is good code - or at least better than it otherwise would be. I don't think that's actually a wild claim.
However, I don't think TDD even ensures testability, especially in javascript/node and similar languages. You can always use goofball mocking frameworks, reflection, and monkey patching to brute force a test into working. That's what I wrote this blog post about.
I see real wonky tests a lot, and am confronted by test automation skeptics with bad past experiences, and so I wrote the blog post really for that audience and also for the people who _DO_ claim TDD forces a high quality design.
There's a great book by Michael Feathers on this very subject called "Working Effectively with Legacy Code".
He takes a strong "test first" approach and talks about all the work you have to do when working on a system that isn't testable to change it safely with TDD.
Howdy - this blog post is responding to folks who do claim that TDD makes it "literally impossible" to design bad systems. This is a fairly common claim among TDD advocates, and I think it makes it harder for learners and skeptics to understand the methodology.
I'm not attacking TDD, I'm a big fan of TDD, I'm just attacking the claim that TDD forces good system design. I understand in retrospect why the title of the piece reads as click-baity, but that wasn't intentional.
I only just noticed this morning that this got shared over here to HN, so now I'm gonna poke around here and find out what horrible things yall have been saying about me ;P