TDD in this sense of building a test suite before ever having working code, or even worse, the style of TDD that Uncle Bob presents in his book, where you write some test code, then some production code to make the test pass, then some more test code, then some more production code etc. is a fantasy and/or a disaster. Especially if we're talking at the level of unit testing: unless you have a very clear outline of the code that you're going to write, and unless the problem is very well specified, you'll throw away 90% of the tests you've written as your code evolves, wasting inordinate amounts of time in the process.
Regular static typing (assuming you don't go to the level of dependent types or something) has the advantage that it is extremely quick to write, compared to an equivalent test. So even if you get the types wrong 90% of the time on the first pass, you've still wasted only a trivial amount of time (consider how long it takes to write "int foo(int x)" versus tests that fail if "foo(x)" accepts anything except an int, or returns anything except an int for any int input - and how much work you'd throw away if you later realize you have to replace int with string).
If you write unit tests for what you're trying to achieve, and then after you achieve it it turns out you didn't get everything right and the code was supposed to do something different, then those unit tests were almost pure waste: you have tests that assert your code is doing the wrong thing (which you thought was the right thing intially). So not only is the code wasted, the unit tests that tested it, which are likely much more code overall, are added waste.
>If you write unit tests for what you're trying to achieve, and then after you achieve it it turns out you didn't get everything right and the code was supposed to do something different, then those unit tests were almost pure waste
And the code changes were pure waste too.
That's why it's important to try and reduce the risk of building to the wrong requirements wherever possible - fail fast and often, use spikes and experiments, use lean, etc.
It's why it's important to reduce the cost of writing tests and code as much as possible too.
Writing the test itself and showing bits of it to others can actually help uncover many requirements bugs too. That's called BDD.
However, if it turned out it was the right thing and you didnt write a test you've just made it much harder to change that code in the future without breaking something. The cost of code changes went up.
Yes, I said so as well. Though it's also important that the code changes are likely to be the thing that reveals that the feature is misunderstood/badly specified. Lots of people can take a working feature and tell you if it addresses their problem. Much fewer can look at a set of unit tests and tell you the same.
> However, if it turned out it was the right thing and you didnt write a test you've just made it much harder to change that code in the future without breaking something. The cost of code changes went up.
Very much debatable. If the code needs to change because requirements themselves change in the future, the tests that are validating the old requirements are not helpful. And many kinds of refactoring also break most kinds of unit tests too.
From my experience, unit tests are most useful for testing regression cases, and for validating certain constrained and well defined parts of the code, like implementations of an algorithm. They're much less useful for testing regular business logic - integration tests are a much better solution for those.
Regular static typing (assuming you don't go to the level of dependent types or something) has the advantage that it is extremely quick to write, compared to an equivalent test. So even if you get the types wrong 90% of the time on the first pass, you've still wasted only a trivial amount of time (consider how long it takes to write "int foo(int x)" versus tests that fail if "foo(x)" accepts anything except an int, or returns anything except an int for any int input - and how much work you'd throw away if you later realize you have to replace int with string).