Suite smells: testing legacy code

There are some good tips here.<p>One comment about this:<p>&gt; But what if you can’t add a test for something because the function is untestable? You could refactor it to be testable, but that’s not safe, because you don’t have a test. It’s Catch-22.<p>&gt; Can we do better? Here’s one emergency rescue procedure for untestable functions that I’ve used successfully. Ignore the existing function and write a test for the function you’d like to have. Then make that test pass by writing a new function from scratch. Finally, delete the old function.<p>But how do you ensure that the new function replicates the same behavior of the old one? What&#x27;s suggested is essentially to do a rewrite, but that&#x27;s as risky as introducing any change to the untested code.<p>One alternative could be to test at a higher level by adding an integration or E2E test. This way you encode how the system should behave functionally, which at least gives you some safety net to do lower-level changes. Then you could refactor the function to make it testable, or use the rewrite approach to remove it altogether.

&quot;Eventually, though, the cost of adding anything to an untested codebase becomes unmanageable. Indeed, the cost of touching the code at all becomes so high that everyone starts finding excuses not to do it.&quot;<p>Dunno about this. In my experience test makes it harder to add code, since usually way too many tests test implementation details.<p>Pair this with some process heavy and written in stone agile methodology and arcane CI environment (which shows test failures on a tv in the break room). And you can&#x27;t easely change the tests since that code is not your team&#x27;s.<p>Like, if the author can smell so can I.<p>The problems he write technical solutions to are social not technical.<p>Even using the concept of &#x27;code smell&#x27; makes my alarm go off. We would have been better off without all these missused rule of thumbs and aphorisms.

&gt; See if a small block of lines around where you’re working can be extracted into its own little function [...] add a little test for the little function, and make your change, leaving the rest of the code alone.<p>To me this is the best compromise.<p>You can:<p>- change code without worrying about breakage<p>- ensure your new code is tested<p>- not have to worry about long LOE that comes with trying to scope in writing tests for the entire codebase