2 ms·
Surprisingly, the article doesn't engage with this argument! Unless I missed it, the author never mentions that unit tests can make refactoring other code easie
by nrook 7y ago
Surprisingly, the article doesn't engage with this argument! Unless I missed it, the author never mentions that unit tests can make refactoring other code easier.
In my experience, after code is checked in, unit tests have two main purposes:
1. Checking that functions aren't completely broken in dynamically typed languages (i.e. a check so basic that a static type checker can do its job)
2. Allowing programmers to refactor code without being terrified it will break something far away in the execution path
And like, that's it. That's enough to make them useful to have around.
- tsimionescu 7y agoI don't think I've ever seen unit tests that didn't need to be changed fundamentally to deal with any sort of refactoring more complex than extracting a function. Unit tests are supposed to work with the internals of a module and not just its boundaries. Since refactoring normally tries to significantly change the internals without changing the boundary, it usually also results in a rewrite of the unit tests. Integration tests are the ones that usually help me sleep better after a refactor.
- nrook 7y agoI don't think I agree with your premise, but even if I take it as true--- it's the unit tests of the other modules that help me out, by ensuring I haven't managed to totally bust the module I'm working on. Some people argue that a unit test of a module should mock out its dependencies and not rely on them. For unit tests like that... well, I endorse the article.