What he said is, if you dont create tests first, refactoring is just changing shit. The behavior is supposed to be invariant across refactoring. The only way you can be sure is to test the before and after.
Won't it be nice when we have refactoring tools that are trusted enough such that you can remould code (even legacy code) without the pain of writing unit tests?
Moving from C to Java you really appreciate tools like IntelliJ and Eclipse which can automate some refactorings with a fairly high amount of certainty that it's not going to change the behaviour.
The safe refactorings included in IDEs have a far higher bar of safety than mere testing; if the code is syntactically correct and there are no escapes from the static type system used (such as reflection), then the refactorings are proven to be correct, no testing needed.
Reflection does not break the static type system in any way. However you are right in assuming the refactorings are in general not correct in the presence of reflection.
In fact, testing the software is not just there to make refactorings possible. The tests for the software are there to check if the software behaves correctly for a (hopefully representative) set of inputs.
Thus, the check if a refactoring is invariant is mostly a side effect from having a test suite for your software, and thus, in my opinion, it does not matter how secure your recfactorings are. I do have my tests already!
(And yes, I do consider it a heavy code smell if there are no tests written, because lots and lots of things are so very, very easy to test if structured ... if structured ok. not even well structured, just without hard-coded dependencies)
The thing is, I don't really like "tools" for refactoring, because they take me a little too far away from the code.
For example, they might make mistakes, like changing only the code references and not the comments; or be mildly annoying by screwing up indentation.
I feel better being forced to visit every line, to see the whole scope of the change and realize just what it's doing to the code. Occasionally, this has made me realize that the refactor is not even the right thing to do. Also, it is one of the few chances I have to force myself to read code that I don't visit often; it can result in me writing down a few other things to go back and fix later (a mini-code-review, basically).
