They are a compile time contract at best, they are nothing like a test.

Test and compile time contracts both check invariants.

Abstractly speaking, there's no big conceptual chasm that separates a test in a test suite from a test the compiler makes.

A lot of tests end up testing things which would've been caught by the type system. Static and strong typing doesn't make tests in general unnecessary, but it does mean you don't need quite so many trivial tests.

Half the tests I write for Javascript code are type tests. Typescript does that much better.

They are checking the shape of inputs and outputs, making it unnecessary to test that a function returns a value of a particular type or that this value has particular fields. They make sure you don't make stupid mistakes, leaving it up to you to test really valuable bits of logic.

Static types most definitely do not replace the need for tests!

Agreed! They replace the need for specific kinds of unit tests, e.g. making sure your functions accept and return the correct shapes. You still need to test the actual logic, and should be doing some sort of integration test on the application as a whole.

In retrospect, my original response was too terse. Static typing and testing serve the same purpose, which is to make sure your application runs according to some measure of correctness. We shouldn't be setting up one-or-the-other dichotomies — we can have both!

But it misses the point I was originally making. I was not suggesting they are mutually exclusive.

My interpretation of your point was that unit tests are more valuable than static types, and I don't think that's necessarily true. They're both forms of testing, and it's important to recognize their strengths and weaknesses.

Static types won't help with your application logic, but they will (for example) ensure your function inputs and outputs are the correct types, help document your code and ensure consumers call your code correctly. Unit tests can only do the first one, and it's more verbose and brittle.

Your statement and the one you're responding to are wholly compatible.

They aren’t, and it’s detrimental to think of them that way.

Why do you think so? I think they're better than equivalent tests, and in fact help bring about better testing.

A lot of unit tests will revolve around checking types. If you don't have to runtime-check this, you can focus unit tests on semantics and integrations assuming the underlying data structures are correct.