Thank you David for your response and highlighting the 2 studies/papers.

But I still fail to see which 'bright new idea' TDD brings to the table, how it changes the game.

To be clear: I am convinced of the value of testing (any and all kind of testing, be it unit, integration, functional, performance, ...). And yes, the sooner in the development cycle you can test, the less costly it is to fix.

In my experience, I am not alone in this.

Even the good old V-cycle highlighted the importance of testing. They even went so far to link the different types of tests to the different aspects/levels of design. Just have a look at e.g. https://www.researchgate.net/figure/V-Model-life-cycle-for-the-automotive-software-testing_fig1_314665883

Granted, many people seem to inteprete the V-cycle as a strictly sequential process, with multiple different teams responsible for each step.

Which is an mis-interpretation IMHO (or maybe an over-interpretation).

The only thing the V-cycle says is that

- before you write the code, you must define what the code must do

- before you release/deploy the code, you must validate if it does what it is expected to do

So there is nothing in V-cycle that says you can (or should) only start writing tests after you have completed coding. You are allowed to write them upfront or in parallel or whatever.

There's also nothing that says you should only start testing once all code has been written. You can deliver solutions in an iterative and incremental approach.

In my experience, many organizations and teams already do it like that long before people started talking about TDD (or Agile for that matter).

But yes, some teams don't do it that way, some don't even bother with testing. Ah well.... survival is not mandatory.

[Oh yes, not sure if having to deliver a bug fix right before a rocket launch is evidence of the power of TDD. It just shows that bugs can and do escape from testing once in a while... so you should be prepared for delivering fixes quickly if needed]