What are the pros and cons of refactoring code during the testing phase? Are there any set methods of doing this?
You avoid this question completely by integrating testing into software development life-cycle. I assume you mean that the bulk of testing is done after development, rather than "how do we re-factor in the 11th hour of final testing"?
General advice for re-factoring is to have good test coverage so changes can be made with confidence and have a high degree of automation so more tests can be run quicker.
Unless you have a really really strong reason to refactor during testing and the unit/functional/acceptance test to check your changes, I'd say don't. Nathan Cooper points out that good code coverage will ease this pain of refactoring and I agree. Your question implies a distinct "code then test then deploy" workflow so changing stuff in the coding phase is going to draw out the testing phase.
Pros: - Your code will be better organized after refactoring, though by definition, it won't be any more functional than it was before the changes. Refactoring is just to change the structure of the code base, not its behavior.
Cons: - You can potentially introduce bugs that your tests won't catch. Remember that any time you make a change, there is a potential to introduce a bug.
You'll have to calculate the costs associated with the risk of introducing a new bug during the testing phase.
In general, how many changes you tolerate in flight is tempered by your test coverage.
Imagine a case where the team wants to complete a large refactor while implementing a new large feature.
If you have robust test coverage, then this case may not be daunting. Presumably because the cause of errors can be identified with higher speed and certainty.
However if you have anemic test coverage, then this case may be horrifying. Presumably because the cause of errors consume more investigation effort.
To answer the question of pros and cons:
- Greater velocity
- Greater risk