Add tests to the function as it exists today. Submit. Add new functionality, make sure tests still pass. Done. Updating a function here and there shouldn't require more staff.

This implies adding tests that accurately capture all the nuances of the function and don't test the simplest logic need to hit code coverage. When we are talking someone new to the function, then this is about the same as asking them to learn the function so they can be sure they didn't make an error when they changed it. The benefit of tests is that they are written by the person creating the function originally who is most aware of the hidden dangers of it.

I'm distrustful on unit testing as I've seen too many tests written to make code coverage numbers but that don't actually test the functions they are aimed at. A non-trivial number which run the function asynchronously and then report a successful run before the function even finishes executing, meaning that even throwing errors don't fail the tests (granted, part of that is on the testing framework for letting unexpected errors ever result in a pass).

Of course, this is the way you need to write tests -- to test the actual logical pathways and requirements of the code, and not just finagle them together to overfit some code coverage metric.

We have a saying at my work. "If you like it, then you should have put a test on it". If the original author didn't add adequate coverage and you end up breaking them, it's on them.