The delivery of a text depends on the literary goal of the author.

When you created or found a new way do approach development and you want to spread that idea, you want to persuade.

Alternatively you may want to inform, for example when you teach or journal. In which case you write down the facts without embellishing them.

Finally you may want to do a critical review, then you explain the method in relation to other methods and existing practices. Pros and cons, etc.

The hope is that the reader will understand these goals and adopt it into their own beliefs as they see fit in relation on how it was presented.

The charitable interpretation is that this is just the definition of TDD, and the author isn't actually trying to push it on anyone. I completely agree with you though - pushing TDD as "the best" is just obnoxious until someone comes in with some more solid evidence to back it up.

If you do TDD, you write your tests first. If you don’t follow TDD, you don’t have to. The author insists on this because they assume a TDD approach.

I suppose that is a fair reading. If TDD is the goal then the "never" instruction makes sense.

It helps you think about the problem better.

A particular test has assertions that must be implemented correctly in order for them to pass.

By starting in red you gradually make your way towards green usually paving your thinking and potentially unlocking other tests.

I don't believe you must do this every time though.

> I don't believe you must do this every time though.

So I think we agree. If you find it beneficial, please carry on doing it. For anyone who doesn't find it beneficial, they can write tests in whatever way they want.

In the context of the article, I read this as "modify the test first for an existing unit test and a bit of production code under test". I don't think this is equivalent to "always write the test first".

For me it is LARPing, people pretending that code they write is so complicated and so important they need 100% test coverage and nuclear reactor will melt down somewhere if they don’t do their job on the highest level.

I write testable code without TDD and if something breaks we write test to cover that case so it doesn’t happen again.

How do you refactor code, if you have a poor test coverage? Also for me actually the most importan benefit is the instant feedback I get, when I write the unit tests before the implemenation. I can move faster with more confidents.

Probably by working in an environment where that confidence is conveniently provided by static type analysis. If the parts are sufficiently reshaped to fit together again you just know that it will work. And chances are that feedback is an order or two of magnitude more instantaneous.

A lot of software is business processes I.E Money.

You don't want money and ledgers going out of sync. That can be serious.

TDD helps you think about the API as a user, which naturally leads to a user-friendly design, and in turn also makes the implementation testable from the start. Often when testing is done after the implementation, the code is tightly coupled, relies on external state, and requires refactoring just to make it testable.

That said, this workflow is tedious during the exploratory phase of the project. If you're unsure yet about which entities should exist, and how they will be used and interact with each other, TDD can be a hindrance. Once the design is mostly settled, this workflow can be helpful, but insisting that it must be used always is also annoying. Everything in software development is a trade-off, and dogmatism should be avoided.

It is the safest way to make sure your test will actually fail in case your code does not work. I often had the situation where I wrote a test which is always green, if if the code is broken.

Often I do not have the clarity to write the test first, then I just write the code and the test later. But I comment out the code or introduce a bug on purpose to make sure when I run the test code it actually works and detects the bug.

I think you are hitting the key point to make. It boils down too "dogmas are bad".

All these programming methodologies seem to be in risk of developing a cargo cult following and since programmers are way more dogmatic than people in general it also gets way worse than in other fields.

I don't like TDD and I think it is silly. But fine whatever floats your boat. The problems begins when someone tries to push the single right way onto others and it seems to mainly be a problem in corporate settings where most people rather get money than doing what they think is the right thing -- and some people push agile, TDD or whatever.