3 ms·
High test coverage is useful in the environment where the code is not adequately typed. That's because static types adequate to make the code bulletproof will a
by xmcqdpt2 3y ago
High test coverage is useful in the environment where the code is not adequately typed. That's because static types adequate to make the code bulletproof will also detect the problems unit tests could detect, rendering high unit test coverage superfluous.
So, how often is poorly typed code out there? From the popularity of test coverage tools, it must be ubiquitous.
- pfdietz 3y agoThe turned-around argument has a problem: testing should reveal type bugs, but static typing (of the kind typically discussed for mainstream languages) can't reveal non-type bugs. In a situation where extreme levels of testing occurs, the extra assurance from strong typing is minimal. In a situation where strong typing is enforced, extra testing is still very useful.
- xmcqdpt2 3y agoI don't think it's possible to test a sufficiently complex system that isn't somewhat restricted in the states it goes through, which requires typing. Consider a finite state machine with N states. There are a priori NxN possible transitions. In many cases however most of them are impossible, and you really have only O(N) feasible transitions. Sure if you make O(N^2) tests you don't need typing... but typing could have made many of those transitions literally impossible. You don't need to test the impossible. For a sufficiently large codebase, you want to limit as much as possible the amount of tests you need. Also I have more than once identified issues in our testing framework because when I made stronger types I uncovered bugs that escaped our tests. Non-deterministic concurrency bugs are extremely hard to test for. So yes, testing can uncover type bugs, but typing can uncover untestable bugs.