4 ms·
I write unit tests so that I can refactor fearlessly. How does the author handle situations where he can either 1) put in a hack to fix a bug or handle a featu
by helmut_hed 16y ago
I write unit tests so that I can refactor fearlessly. How does the author handle situations where he can either 1) put in a hack to fix a bug or handle a feature request, or 2) restructure the code to make it fit the modified problem description better? If you have unit tests you can do the latter, and feel good about what you have. If you don't have a testing infrastructure, you must do the first, because you have no confidence about how the behavior of the code might change and you have to be paranoid.
- dalke 16y agoI don't understand how anyone can be fearless during refactoring. Suppose I refactor string search from the simple version (worst case time O(n*k)) to Knuth-Morris-Pratt (worst cast time O(n+k)). The API is unchanged, so this is an excellent example of a refactoring. But the KMP implementation has so many more edge cases where I might make a mistake that I wouldn't be comfortable using only the tests uses to drive the simple version. I would be happier with code coverage-based tests, or better, branch coverage-based tests. That would help tell me which parts of my new implementations need test cases, although it wouldn't be sufficient. Would you really be fearless for this type of refactoring? And how does following TDD practices help out? It seems to make the fallacy that refactoring is trivial and therefore doesn't need additional testing.