If a refactor is pissing me off....I'm doing it wrong.

Last week I had to re-factor a class that we created a long time ago when our practices weren't at the same level as they are today. At one point(after a few changes and check-ins) I basically was only left with moving a method from the class to an other class. That simple refactor caused a small nightmare. The method was used in only one place in the application code but in 40 plus various unit tests.

A quick glance at the tests made me realize I had to replace the existing mock with a mock the new class. That didn't seem very hard but it wasn't as simple as I would have expected. At this point I was quite discouraged. I was tired and pissed off at all the duplication in the tests and felt I could not afford to do a full refactor of the unit tests before I made the change.

In that mindset I felt that what I had to do was remove the method and make the application compile by replacing all the broken usages. I also had to make sure the new mocks didn't break the tests and that code was a mess. Finally only after I had fixed all the code was I going to be able to run the unit tests and hope all was green. NONSENSE!

I was a long way from being able to compile and run the tests. But that's still how I did it.  After getting the code to compile I ran the tests an some tests did indeed fail for various reasons. None of which were caused by a bug in the application code. I fixed it all up and many hours after I started moving the method I finally made my check-in.

Today with some insight from a team mate I realized that contrary to what I felt at the time the re-factor was not painful because of bad code. I was painful because I just assumed the bad code was making it painful. When I realized the work involved with that small change was pissing me off I should have taken a step back and asked my self if I was going about it the wrong way.

With hindsight I now realize that... 

I did not have to: (method a)

1. Delete the method. 
2. Fix a usage.
3. Stress because I cant run the unit tests because the code still wont compile.
4. Repeat steps 2 and 3  until all the broken usages are fixed.
5. Run the unit tests
6. Cry
7. Fix the unit tests
8. Check-in.

What I should have done: (method b)

1. Replace the usage in one unit test. 
2. Make the the test go green.
3. Refactor to eliminate the duplication that caused all the usages in the unit tests. 
4. Repeat steps 1-2-3 until all the usages are changed. 
5. Remove the method. 
6. Check-in. 

An other option??:(method c)

1. Refactor the unit tests to remove most of the duplication that caused the headache.
2. Proceed with the planed re-factor as I did in method a. 

An other option??:(method d)

1. Refactor the unit tests to remove most of the duplication that caused the headache.
2. Proceed with the planed re-factor as I did in method b. 

I think I prefer method b because I feel it keeps the scope small for each iteration of the refactor.

 As it stands I got things to work but it was more painful and stressful than it should have.  But the duplication in the unit tests that caused the head ache is still there ready to make a subsequent refactor an other nightmare.