4 ms·
Full test coverage of foo() is hard to prove. Have you exercised every argument possibility, every exception that could be thrown and every global/class/instanc
by glennpratt 8y ago
Full test coverage of foo() is hard to prove. Have you exercised every argument possibility, every exception that could be thrown and every global/class/instance var reference? Working with Ruby most of my career, my experience is probably not.
A good type system is much more thourough and let's your tests focus on behavior.
- vidarh 8y agoThat's what you have coverage checkers for. And you don't need full coverage. Aiming for full coverage is a folly - you aim to cover the API surfaces you're actually using. If you still get lots of runtime errors something is very wrong with how you test your code. > A good type system is much more thourough and let's your tests focus on behavior. The problem is no languages I'd be willing to use have a good type system that actually covers much.
- glennpratt 8y ago> The problem is no languages I'd be willing to use have a good type system that actually covers much. This is basically down to opinion, and I can't argue with it. I've collaborated on Ruby projects for about 10 years, I love the language, but my experience says a large code base, with test coverage, regularly breaks on things that most type systems wouldn't allow. Dependencies often cause subtle breaks like this, even in big, common ones. On top of that, this requires paranoia to avoid breaking callers. With a good type system, you can largely discard that paranoia.