<i>And if you refactor without tests, “you’re not refactoring; you’re just changing shit”.</i><p>I'm reluctant to contradict this, because I am a fan of unit testing, but: it is entirely possible to safely refactor many programs that lacks unit tests by being disciplined about how you sequence the changes that you make. If you break down and organize your entire refactoring effort into a sequence of tranformations of your source code T1, T2,...Tn and you can prove to yourself that each step along the way that the behavior of your program did not change as a result of each step - and you can execute this sequence with fidelity, then you are refactoring, even in the absence of unit tests.<p>Although it is much better to have a regression suite.<p>Edit: on a more personal note, I remember when I first realized this. I was a young Java programmer, and I was given a class file and told to make it better. I had no idea what this code was supposed to do, and it was written by someone who was more of a project manager that wanted to try Java. It was enormous, and comprised of a mere handful of epic-ly long methods of deeply-nested if statements and loops. Everything was badly-named.<p>I was at a loss to make the code better without even understanding its function, but then my mathematical training kicked in: "...if I can make a sequence of small behavior-invariant transformations..." Aha!