3 ms·
> 3. No one dares to refactor anything ==> Code rottens ==> maintenance hell. In my experience, with enough poorly written unit tests and a hard line policy on
by zmmmmm 10y ago
> 3. No one dares to refactor anything ==> Code rottens ==> maintenance hell.
In my experience, with enough poorly written unit tests and a hard line policy on unit test coverage (which often results in poorly written tests), the unit tests often turn out to be as much a barrier to code maintenance as the regular code is.
I'm an advocate of judicious unit testing, but taking it too far is worse than not doing it at all if you have integration or system / functional tests IMHO.
- dzhiurgis 10y agoSounds like my life these days. Been given some smelly code (2k loc) that I cannot fully comprehend, so I just went out and naively refactored it. Code was covered without assertions, so I insisted spending some time into writing at least a few while everyone else just asked me to test. And of course once in production tons of bugs started to appear. I still believe I can write system tests though.
- brianwawok 10y agoThis is the real trick. Unit tests encourage you to maintain abstractions and layers. If your abstractions are good it works well. But if you need to change abstractions it now becomes a much harder problem. One nice part of more system level tests than unit tests. Hi ahead ans refactor a bunch. If the same inputs still give the same outputs you should be golden still.
- jacquesm 10y ago> If the same inputs still give the same outputs you should be golden still. That's dangerously subtly wrong. It only holds if your inputs include both positive and negative cases. If you only push positive cases through your code and it still gives you the same outputs then it might be broken in subtle but non-obvious ways, aka happy-path testing. Better be very careful with this.
- brightball 10y agoYou can refactor anything if you are conscious of backwards compatibility.