4 ms·

The question of whether it's "worth it" really boils down to you and your specific requirements. Even within the same project, there are times when I don't wan

by LASR 4y ago

The question of whether it's "worth it" really boils down to you and your specific requirements. Even within the same project, there are times when I don't want typechecking - when I am prototyping something out and want to move fast. And there are other times, when I want typechecking - when I am finalizing a feature implementation or doing integration with existing logic etc. It's not a framework. It definitely is a language in its own right. But from personal experience, the group productivity goes way up with larger codebases with many ICs working on it. Unit tests become type checks. It opens up a lot of extra bandwidth for more sophisticated functionality or better tests. Solo IC, working on a small project, with no intention of ever writing tests - you might see TS be an overhead. To sum up, your requirements decide whether it's worth it.

roberttod 4y ago
I have seen this IC vs team aspect discussion before, and it definitely has merit. However I am starting to question if it's even worth it for larger codebases used by many devs, which is why I wanted to pose this question. Can you think of cases where it's actually prevented a bug where that piece of code is unit tested? I have been actively monitoring for this to happen, but so far not seen it (I think I have seen it catch a couple of bugs for code that did not have unit tests).
- brundolf 4y ago
  Unit tests only trace one path at a time; static types cover huge possibility-spaces at once. But of course there are things they can't reason about, which is why we still test, but each of the two is better for catching different kinds of things. One isn't sufficient to replace the other.
- 8note 4y ago
  A unit test can succeed while being completely wrong. Eg. You test code that calls a dependency that returns a bool, but your tests assume an object response Unit tests imply assumptions about the integrations, whereas types specify those asumptions
- eddsh1994 4y ago
  Types let you limit the size of the input space - JS lets you go ahead with (foo, bar) where they could be literally anything and you have to handle every edge case to test that (and I bet if you fuzz you'd find stuff) your unit tests don't handle. With a typed language I can specify the input space and know with certainty anything that calls that function (and compiles) is going to be within that space. This lets you dramatically reduce the complexity of your app, tests, and stress of refactoring! Fwiw I'm an SDET and I regularly find bugs, on a daily basis, in a startup of around 40 people with a Python/JS web stack that TypeScript would have caught (and am pushing towards moving over to it).
8note 4y ago
Solo ic on a small project, you don't write tests? That's the easiest time to write tests! You don't have all the complicated context set up or writing test data, and saves you the run/debug loop for setting up specific situations. My childhood not knowing about tests had a ton of wasted time trying to check that a change worked

by LASR 4y ago

roberttod 4y ago

I have seen this IC vs team aspect discussion before, and it definitely has merit. However I am starting to question if it's even worth it for larger codebases used by many devs, which is why I wanted to pose this question. Can you think of cases where it's actually prevented a bug where that piece of code is unit tested? I have been actively monitoring for this to happen, but so far not seen it (I think I have seen it catch a couple of bugs for code that did not have unit tests).

brundolf 4y ago
Unit tests only trace one path at a time; static types cover huge possibility-spaces at once. But of course there are things they can't reason about, which is why we still test, but each of the two is better for catching different kinds of things. One isn't sufficient to replace the other.
8note 4y ago
A unit test can succeed while being completely wrong. Eg. You test code that calls a dependency that returns a bool, but your tests assume an object response Unit tests imply assumptions about the integrations, whereas types specify those asumptions
eddsh1994 4y ago
Types let you limit the size of the input space - JS lets you go ahead with (foo, bar) where they could be literally anything and you have to handle every edge case to test that (and I bet if you fuzz you'd find stuff) your unit tests don't handle. With a typed language I can specify the input space and know with certainty anything that calls that function (and compiles) is going to be within that space. This lets you dramatically reduce the complexity of your app, tests, and stress of refactoring! Fwiw I'm an SDET and I regularly find bugs, on a daily basis, in a startup of around 40 people with a Python/JS web stack that TypeScript would have caught (and am pushing towards moving over to it).

8note 4y ago

Solo ic on a small project, you don't write tests? That's the easiest time to write tests! You don't have all the complicated context set up or writing test data, and saves you the run/debug loop for setting up specific situations. My childhood not knowing about tests had a ton of wasted time trying to check that a change worked