Others have already posted comments defending their subjective love of type systems. But there is an objective observations I would like to add:
Using a good type system, you can prove your program's correctness on type level, because it makes writing a program the same thing as formulating a mathematical proof.
With a test, all you have is a sample. If and only if your code is pure, such a sample proves you that your code works on the sampled input.
Of course (human) testing has its own strengths; for one, it can find problems in the algorithm itself rather than its implementation.
As a practical example of the value of typing (with monads) I'm going to point to the obvious NoRedInk example.
Hmm... I agree on type level correctness with you.
But, this goes onto the critical issue with TDD, most people misunderstand it and tend to talk about the code coverage metrics where it all got wrong.
Suppose you do TDD on the business rules metrics and 99% of them are well tested, meaning all the behavior your code is correct (from the business perspective)... would you really care about type level correctness?
As for the NoRedInk example, this got to do also with the TDD and it's an exceptional case IMO.
People tend to test JS frontend code, and what is JS mostly doing? it manipulates the DOM / BOM... UI stuff.
Basically UI testing is glue testing, you change the UI tomorrow, and you gotta change the tests too. It's like testing 1 + 1 = 2.
That's where elm typing is really great, you don't need to test UI, however you verify what you're doing with typing ;)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.