The two are completely unrelated. When I was writing vanilla JS it felt like half my tests were just focused on ensuring that everything remained the type it was supposed to be. Not in a static type sense but in a duck type sense at least - does this object still have field X? Can I still call function Y on this object? Is this variable still defined?

All those kinds of tests can be eliminated with static typing. It's true that a lot of those types of errors would get picked up in functional tests, but at least from my perspective it's not great practice to rely on a functional test to catch that kind of change. If your functional test changes it's easy to lose coverage of your basic unit tests that were only happening implicitly.

Funny how you say the two are completely unrelated and then go on to show how they are related with your personal experience.

While you're technically correct, this misses the value of static type checking vs type checking in tests. Tests must be written manually, must check every code path and must be updated whenever the underlying implementation changes, in order to achieve the results of static type checking. But types are declarative and will be checked automatically for every code path called.

1. If you dob't have tests covering code, sure type checks are better than nothing. but if you do, why do you also need type checks?

2. If the tests must be updated whenever the underlying implementation changes it might be testing too much- it's better to test behaviour, not implementation.

I was addressing the above comments about tests that specifically check types. My position is that declarative types and a type checker are better because each code path is checked automatically without writing additional tests, and because the type checker automatically adapts without changing or writing new tests when the implementation changes. Testing behavior is another thing entirely.

I'm not missing the value we just have a different idea of what that value is, but anyway, this is a different, more specific topic than the one I originally brought up and one that I don't feel like engaging in.

I think it exactly addresses your original topic, but you're in no way obligated to engage it further. Have a nice day!

Static types are a form of test!

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.

Just a nitpick, but Typescript adds static typing, not strong typing. The types are still weak because implicit type conversions still exist:

  const x = "one two" + 3;

I think you can make either your typescript or tslint config error out on this at compile time. I think this is configurable.

sounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.