4 ms·
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing.
by ianwalter 8y ago
Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing.
Edit: changed strong to static.
- janpot 8y agosounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.
- jakelazaroff 8y agoStatic types are a form of test!
- lucisferre 8y agoThey are a compile time contract at best, they are nothing like a test.
- mort96 8y agoA 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.
- azangru 8y agoThey 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.
- Sammi 8y agoHalf the tests I write for Javascript code are type tests. Typescript does that much better.
- coldtea 8y agoTest 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.
- enraged_camel 8y agoThey aren’t, and it’s detrimental to think of them that way.
- aylmao 8y agoWhy 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.
- starefossen 8y agoStatic types most definitely do not replace the need for tests!
- asnrk 8y agoYour statement and the one you're responding to are wholly compatible.
- jakelazaroff 8y agoAgreed! 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!
- ianwalter 8y agoBut it misses the point I was originally making. I was not suggesting they are mutually exclusive.
- jakelazaroff 8y agoMy 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.
- mason55 8y agoThe 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.
- ianwalter 8y agoFunny how you say the two are completely unrelated and then go on to show how they are related with your personal experience.
- eyelidlessness 8y agoWhile 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.
- amikazmi 8y ago1. 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.
- eyelidlessness 8y agoI 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.
- fingerlocks 8y agoJust 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;
- mevile 8y agoI think you can make either your typescript or tslint config error out on this at compile time. I think this is configurable.