> the current implementation might have used a clever trick to achieve faster execution (this cannot be evaluated with unit tests). Sure it can. I worked on a

> the current implementation might have used a clever trick to achieve faster execution (this cannot be evaluated with unit tests). Sure it can. I worked on a project with a pubic API with many time sensitive routines and we most definitely had unit tests measuring performance. The test failed if the execution time exceeded the acceptable threshold. > Alternately, it might have been implemented so as to share common functionality with a different piece of code by calling a common subroutine. You can certainly write coherency tests to ensure that two methods are doing what's expected. They might not share the same subroutine any longer but you can throw an exception when their respective results no longer align and have comments on the test explaining the rationale. Honestly if you have this sort of subtle dependency and you don't have a unit test for it then you're just asking for trouble.