Safe legacy code refactoring

As soon as I was deep into the legacy code refactoring, the pinttests creation start to be a lot of pain.
It was a good exploration tool as well (and NCrunch rules for this purposes 100%) and following all the red dot's you can find a lot of interesting places inside the legacy stuff.

I knew upfront legacy code refactoring will be hard, but this requirement to have at least pinttests on top of it to start in some kind of safe grounds - this was really hard to achieve. Even if I have live system available locally for this purpose.

So I asked about my pain on some software meetings, and guys advised me to stick with this behavior only on the final stages, as soon as we have some pretty nice tools in our hands (like ReSharper, for sure) and we can make some easy refactorings without any test coverage and still have high level of confidence we don't break anything.

For example, if you have raw File.Exists calls in your code, you can easily extract method FileExists from it with the same parameter, doing the same File.Exists inside.
Then you can extract this (and maybe other File.* methods) into the FileProxy class just using ReSharper refactoring tool.
Then you can use old style wrapper around the local variable holding this FileProxy to initialize it if null, or you can use Ninject - whatever appropriate.
And if you have chain of constructor calls inside the same class, you can create a copy of the one you're using inside your tests and add this FileProxy dependency as the additional parameter so you can inject it from the test and use it in the tests instead of the old one.

Initially, I think it's not worth it to start faking this new possible context and going to get rid of the real files dependencies, as soon as in the pinttests context you're going to make a lot of setups just to make it work.

We can still use the same FileProxy in pinttests, but it will be ready for mocking when we're going to the real refactoring process of this giant 6+ screen method.