8 ms·
If you have 100% code coverage you don't necessarily have 100% path coverage, so there could still be errors that a statically typed language would catch at com
by docmach 17y ago
If you have 100% code coverage you don't necessarily have 100% path coverage, so there could still be errors that a statically typed language would catch at compile time. Realistically, most programs aren't going to have extensive test suits that get anywhere near 100% code coverage, so static typing becomes even more valuable. Also, running a full test suite for every build would take much more time that running a type checker.
- gaius 17y agof you have 100% code coverage you don't necessarily have 100% path coverage That is an absolutely crucial point in languages where side-effects are not controlled.
- jules 17y agoAnd also for languages where side-effects are controlled.
- camccann 17y agoBut it is easier when you're dealing with a "pure" function. In something like Haskell, a function that doesn't touch any of the stateful sequencing monads is guaranteed to neither alter nor depend on any sort of global state. In my experience, the times that lack of path coverage gets you into the most trouble is when one large-ish function depends in subtle ways on global state, and inevitably there are bugs involving one or two global states that you don't catch in testing, and then you get errors out in production and have to figure out what on earth is causing it. Not fun.