If you are using a language that is amenable to it, you can refactor at will and the IDE will verify its correctness.

Many people use unit tests as a crutch for a lack of strong typing.

This isn't always (or even usually) true. Sure, the IDE will verify the compile time correctness of the code, but unit tests check for run time correctness. So if you refactor a method to add an additional parameter, unit tests will catch the null that Eclipse inserted into all method calls to make the code compile.

But that is not refactoring, that's adding a new feature!

If you are changing the signature of a method that is part of the implementation in order to improve readability, clean up design, or remove dead code, it is refactoring. Refactoring isn't just as simple as renaming classes and methods; it often requires more significant changes than that.

Example:

  /* old */
  LoadWeapon(WeaponTypeEnum type);
  UnloadWeapon(WeaponTypeEnum type)
  LaunchWeapon(WeaponTypeEnum type);
  /* new */
  WeaponCommand(WeaponTypeEnum type, WeaponCommandEnum command);

Note... assume that the interface is a GUI, so changing these methods doesn't change any external interface.

Not really. Reordering declarations, for instance, is a "safe" refactoring, though not when you're using reflection at some point.

The nulls point to a lacking type system.

You'd need a halting problem solving IDE for this to work in general.