This is indeed too often overlooked. Producing a test list and picking the tests in the right order is definitely a crucial skill to practice TDD. It goes hand in hand with software design skills.

All good points. Can we improve? Sure. Does it means we do it bad? No. Just do it more when it makes sense.

Indeed, don't mindlessly add tests. I find interesting that the doubts raised in this piece are once again concluded using an old quote of Kent Beck. What he was proposing was fine and then over time people became clearly unreasonable.

Nice talks, debunks very well quite a bit of the fallacies around people wrongly practicing TDD. I never realized how the root cause of those fallacies was the misusing of the "unit tests" term instead of "developers test". This was indeed the wrong term, knew it, but first time I realize how profound the effects were.

This is apparently a much needed clarification. Let's get back to basics.

Definitely this. Again TDD helps to work on the design, but it's not a silver bullet which will give you the right design on a platter.

Good summary that TDD is many things... it helps for quite a few dimensions of writing code, still, it's not a magic bullet in term of design. Your software design abilities are crucial to practice it well.

What are the outcomes of TDD? Do you want them? If yes, is the context compatible?

Definitely this, the message is often coming across lacking nuance. TDD can help you towards good design, but it's not ensuring you'll have a good design.

Neat, short and simple post highlighting the important traits of TDD.

This what we should strive for with our tests. I like how he keeps it flexible though, again it's likely a trade-off so you can't have all the properties fully all the time. Still you need to know what you give up, how much of it and why.

Good piece. I like how it frames the debate, asking the right questions on where might be the assumptions on how testing is done.

Indeed, I encounter that same idea in some people. I'm unsure where it comes from, it feels like reading and extrapolating from something more reasonable (it's like the "one test per line" I sometimes hear about). Bad idea indeed, it's fine to have several assertions, it's probably often required to avoid complexity explosion in your tests. This of course doesn't mean your test should become unfocused.

Lots of very good points, I'm a proponent of TDD but I strongly agree with this. If it's painful and not fun, find a way to do it differently. There's likely a tool or some API you miss. Manage your effort.

Excellent piece on joy being a better drive than discipline. This then dabbles into why TDD might not work for you.

Some good points in this list although I'm not in full agreement with everything (especially the one about the lack of usefulness for TDD). The importance and the impacts of the tooling is often underestimated indeed. The last two random opinions about mocking and overtesting are very much true as well.

Likewise I'm more and more unconvinced about the unit vs integration tests distinction. It's likely a continuum between them. I like the proposed axes for classification here. I wish they'd be a bit more orthogonal though.

Excellent answer, really loves how humble Ron Jeffries writings usually are. I like how he doesn't prescribe what to do, but instead describes what happens to him when he does something he shouldn't (or doesn't do something he should). He's definitely human and slips like us all.