I don't understand.

Code does things, tests verify that it does the things I thought it did. Getting a bit of validation makes me feel good while working.

If it now needs to do completely different things then it needs different tests.

Also, if you are making huge changes to tests whenever you change a single detail, that's an issue with your code, not testing in general.

Type checks are good too. Using a typed language is even better.

This reads to me as means/ends confusion. If you write your tests afterwards, to reify the implementation of the system, this is true. They may then require radical changes when the implementation changes. On the other hand, if you write your tests first to reflect business rules and requirements, then those tests will change only when the business rules and requirements change. (Which they will, and that's OK.)

I'm not an all-TDD-all-the-time type by any means. You kind of have to at least have something to start writing tests against or it'll just be compiler errors all day long. But for the projects where I've most consistently found success in building correct systems, writing tests as soon as the basic interfaces are in place has resulted in more flexible, more reliable tests that last over the long term.

As for type checks...isn't that what a compiler is for?