[mohsen1]

> Naively, someone might think you’d write fewer tests with TypeScript. That someone would be wrong.

Have you seen unit tests that check "what if I don't send the right number/type of arguments"? Yeah those unit tests are not necessary if you use TypeScript.

[shados]

They're not necessary in JS either.

You'd presumably have at least some tests in the form of "Give these input, get that output". By checking that output, you pretty much confirm its the right type at the same time.

I've seen a lot of test suites that have stuff like:

"given input A, test that result is defined. Given input A again, test that result is 1234". It's like, yo, if result is 1234, its obviously defined.

There are edge cases, so yeah, the amount of tests you don't write in TS is > 0, but it's far and few in between.

[nicoburns]

It was pretty common to write runtime type assertions at the top of functions in JS before TS was invented...

[shados]

Different topic than unit tests, but also if its in the public interface of your code and you don't control all callers, you might need those assertions anyway (since they could be invoked from non-TS code, or they could have been cast to a any type, especially in non-strict mode TS)

[futureastronaut]

Those assertions are invariants so that the test fails with a meaningful error message rather than raising IndexError or what have you.

[captainbenises]

They are though. What if the API you're relying on doesn't have types and it returns something you didn't expect.

I think this is the biggest gotcha for developers who are using typescript. Typescript doesn't do runtime type checks, so if you're calling out to something third party that isn't written in typescript, you can't trust it'll return what you think it returns.