I test dovrebbero essere strettamente accoppiati all'applicazione.
Il fatto che molti test falliscano quando vengono apportate modifiche è una buona cosa. Molto meglio che gettarlo oltre il muro e chiedere al cliente / utente di trovare gli errori.
Tuttavia, a parte il codice, questo presuppone che tu abbia buoni test in atto.
Alcune domande da porre quando i test falliscono:
Il test è valido?
La logica sotto test è ancora valida? In caso contrario, rimuovilo.
Gli stessi test falliscono?
Se lo stesso tipo di test non funziona, questo evidenzia dove il codice è particolarmente fragile. Un'osservazione irriverente che potresti pensare, ma controlla il controllo del codice sorgente e potresti scoprire che gli stessi test sono stati riparati ancora e ancora e ancora.
Il test è in un'area ragionevole?
Quanto vicino all'azione è il test fallimentare? Se i test stanno fallendo in aree dove non ti aspetteresti, di nuovo, hai un problema che devi risolvere.
Devi massaggiare un test attraverso?
Hai un test che richiede un certo numero di modifiche solo per ottenerle? In tal caso, riprogettare il test in modo da testare un'area di funzionalità più piccola.
Le stesse correzioni devono essere applicate a diversi test?
Se stai applicando la stessa correzione a più test, questo indica un odore di codice. O il test è troppo grande o esiste un codice comune che può essere rielaborato.
Esegui i test seguendo i PRIMI principi?
Verifica che i test seguano le regole di base.
Per quanto riguarda il modo in cui puoi migliorare il codice senza apportare modifiche all'ingrosso, è difficile consigliarlo senza conoscere il codice di base. Come punto di partenza, sarei propenso a indirizzare le tue modifiche sulle aree in cui i test stanno costantemente fallendo.