>No, there can never be irrefutable, objective proof for something that is a best practice.
That's rather begging the question, isn't it? There cannot be proof for the one true way since it's the one true way (or as you call it, best practise)
>In my (subjective) experience TDD a) gives you really good regression tests and b) makes you create smaller functions that are more easily testable and c) makes people think harder about their code.
In my experience, only when those people tended to do that beforehand. And b) and c) don't hold true in my experience either (people are happy to write big functions so their tests pass).
c) is IMO not true either since it feels more like writing code to make tests pass not making code that fits requirements (unless you're good at writing requirements into tests but then why write code to tests code if you could write the code directly?)
>Especially in this case I find TDD very helpful, because it provides a kind of executable documentation of the requirements you just discovered you want.
That's not how that works. I'm sitting in the middle of a function, discovering requirements for that function while I'm writing it and running the application (ie, function does X but also should send an event to Y to clear the cache for user Z who triggered action X)
When you don't have any fixed requirements, applications tend to evolve in-vitro, which doesn't mix well with TDD which is an pre-vitro.
That's rather begging the question, isn't it? There cannot be proof for the one true way since it's the one true way (or as you call it, best practise)
>In my (subjective) experience TDD a) gives you really good regression tests and b) makes you create smaller functions that are more easily testable and c) makes people think harder about their code.
In my experience, only when those people tended to do that beforehand. And b) and c) don't hold true in my experience either (people are happy to write big functions so their tests pass).
c) is IMO not true either since it feels more like writing code to make tests pass not making code that fits requirements (unless you're good at writing requirements into tests but then why write code to tests code if you could write the code directly?)
>Especially in this case I find TDD very helpful, because it provides a kind of executable documentation of the requirements you just discovered you want.
That's not how that works. I'm sitting in the middle of a function, discovering requirements for that function while I'm writing it and running the application (ie, function does X but also should send an event to Y to clear the cache for user Z who triggered action X)
When you don't have any fixed requirements, applications tend to evolve in-vitro, which doesn't mix well with TDD which is an pre-vitro.