Cosa aiuterebbe quando refactory un grande metodo per assicurarmi di non rompere nulla?

Question

Attualmente sto refactoring di una parte di una grande base di codice senza test unitari. Ho provato a refactor code in modo bruto, cioè cercando di indovinare cosa sta facendo il codice e quali modifiche non lo cambierebbero, ma senza successo: rompe casualmente le funzionalità intorno alla base di codice.

Si noti che il refactoring include lo spostamento del codice legacy C# in uno stile più funzionale (il codice legacy non utilizza nessuna delle funzionalità di .NET Framework 3 e successivamente, incluso LINQ), aggiungendo generici in cui il codice può trarne vantaggio, ecc.

Non posso usare Metodi formali, dato quanto costerebbero.

D'altra parte, presumo almeno "Qualsiasi codice legacy refattorato deve essere fornito con test unitari" La regola dovrebbe essere seguita rigorosamente, non importa quanto costerebbe. Il problema è che quando faccio refactor una piccola parte di un metodo privato 500 LOC, l'aggiunta di test unitari sembra essere un compito difficile.

Cosa può aiutarmi a sapere quali test unitari sono rilevanti per un determinato codice? Immagino che l'analisi statica del codice sarebbe in qualche modo utile, ma quali sono gli strumenti e le tecniche che posso usare per:

• Sapere esattamente quali test unitari dovrei creare,

• E/o sapere se la modifica che ho fatto ha influenzato il codice originale in modo da eseguire in modo diverso?