This one keeps annoying me. Having done linguistics in my first degree I should know all about the futility of trying to fix the meaning of words, however I hear a lot of developers using the term refactoring without really understanding what it means.
Refactoring is changing the implementation of a class without changing its behavior. You cannot refactor without testing because you need to check that when you change the implementation the behavior remains consistent. Automated tests, particularly those provided by test-driven development are the key to refactoring being a low-risk operation, because they continue to confirm the behavior of your classes as you refactor them. Refactoring consists of small steps, which are individually safe in the presence of tests, that lead to a bigger whole. Refactoring is documented by Fowler in his book of the same name. Tool support tends to focus on automating some of these small changes.
When you set off to change the behavior of parts of your application, or work without the support of automated tests, or work in large chunks you are not refactoring you are re-writing. Your risk is proportionally high not low. So when you tell your team lead or project manager that you want to do some refactoring in that context, you are being misleading.
Automated testing is vital and it is a key benefit of test-driven design that you will have tests to support refactorings ‘as you go’ thus making your application amenable to low-risk improvement thus preventing software rot. Anyone who has worked on a legacy project (where legacy == no automated tests) knows the pain of never being certain what the impact of even small implementation changes is, such as bug fixes, and how the effect of that is to make applications brittle.