Imagine that you are using a tool that automatically applies a set of refactorings of your choice. If the refactorings breaks the existing API for whatever reason (e.g. change method name, parameterise method or a refactoring that makes some structural changes) do you expect the tool to also automatically change your unit tests so that they all still pass? Or is this something unreasonable to expect?
A good quality refactoring tool with a well organised setup should handle for example renaming. When internals of a method are changed, unit tests shouldn’t be affected.
If you have to change the callers of a method manually, I’d expect you have to change your unit tests as well.
No, I would not expect an automatic refactoring to change test code.
One of the key points behind a refactoring is that it should not ever change the expected behavior of a class*, and as such should never cause a failure of a test covering that behavior.
As a matter of fact, the way that you know a refactoring is ok to do is because the tests that passed before the refactoring continue to pass after the refactoring, without changing the tests.
If a refactoring that you expect to be painless results instead in a broken test, then I would use that as an opportunity to re-evaluate the value of the refactoring, or re-evaluate the test itself, which may be too concerned with the private internal workings of a class.
* based on a standard definition of the term
Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.