Sono necessari (preferibilmente automatizzati) anche test di integrazione / di sistema, a parte i test di unità, proprio per verificare che le modifiche come il tuo esempio non interrompano le funzionalità esistenti - apparentemente non correlate - nel tuo sistema nel suo complesso.
I test dell'interfaccia utente sono molto più difficili dei test unitari, ma ci sono strumenti che possono aiutare almeno un po '. Per le pagine Web, ad es. HttpUnit o selenio sono raccomandati da molti. Se comunichi di più sul tipo di sistema, potremmo essere in grado di dare consigli più precisi.
Un percorso intermedio può essere quello di scrivere test del sottosistema, che sono tecnicamente come test unitari più grandi, possibilmente anche con il DB. DbUnit è uno strumento che può aiutarti in questo. I test di sottosistema possono consentire di verificare dipendenze / ipotesi come quella che descrivi, in modo che se si modifica l'origine dati della tabella T, alcuni test per il codice X non andranno a buon fine, costringendo anche l'aggiornamento di quel codice.
Il problema di fondo è che apparentemente non capisci come funziona il tuo sistema. Questo è tristemente comune per le app legacy, ma le tue descrizioni sembrano suggerire che questo sistema è stato costruito dal tuo team fin dall'inizio - nel qual caso c'è un problema fondamentale nel modo in cui lavori. Devi assolutamente imparare a documentare le dipendenze all'interno del tuo sistema e devi anche lavorare per ridurre e controllare queste dipendenze. Fai attenzione a accoppiamento e coesione nella tua architettura, al fine di dividere il tuo sistema in moduli / componenti indipendenti che si influenzano solo l'un l'altro in modi ben definiti.