3 ms·
I think this is completely false. It completely breaks down as soon as you get into your first refactoring that is a bit larger than completely trivial. Typical
by cjfd 3y ago
I think this is completely false. It completely breaks down as soon as you get into your first refactoring that is a bit larger than completely trivial. Typically the mess one ends up is one or more of the following. (1) Nothing is refactored because people do not dare to do it. (2) Not just some but most of the uncommon code paths are broken. (3) Tools that are used to interact with a running application are regularly in a broken state. You want to prevent these problems with 100% test coverage. As such this may be a laudable goal on occasion but I do notice that the code described in (2) and (3) are highly non-trivial to cover 100%. I also have to wonder what mythical developer is does not have the discipline to use static typing but does have the discipline to attain 100% code coverage. I first want to see such a developer before I believe in his/her existence.
- ActorNightly 3y ago>It completely breaks down as soon as you get into your first refactoring that is a bit larger than completely trivial. This is, in fact, MUCH easier to do with a strong test suite that only cares about input and output rather than internals. The most common approach to starting a refactoring project is write or enhance a test suite to the point where there is no undefined behavior, either the program works or handles the appropriate errors. You don't need to aim for 100% test coverage either, you just need your tests to cover all possible inputs (including fuzzing).