Ho un approccio diverso a questo:
Che garanzia hai che il tuo codice è corretto? O che non infrange l'ipotesi X quando qualcuno nella tua squadra cambia func1 ()? Senza test unitari che ti mantengono "onesto", non sono sicuro che tu abbia molte garanzie.
L'idea di mantenere aggiornati i test è interessante. I test stessi non devono spesso cambiare. Ho 3 volte il codice di prova rispetto al codice di produzione e il codice di prova è stato modificato molto poco. È, tuttavia, ciò che mi consente di dormire bene la notte e la cosa che mi consente di dire al cliente che ho fiducia che posso implementare la funzionalità Y senza rompere il sistema.
Forse nel mondo accademico ci sono prove, ma non ho mai lavorato da nessuna parte nel mondo commerciale dove qualcuno avrebbe pagato per un simile test. Posso dirti, tuttavia, che ha funzionato bene per me, ci è voluto poco tempo per abituarmi al framework di test e scrivere test mi ha fatto davvero pensare alle mie esigenze e al design, molto più di quanto abbia mai fatto quando ho lavorato in team che non ha scritto test.
Ecco dove si ripaga da solo: 1) Hai fiducia nel tuo codice e 2) Riscontri i problemi prima di quanto faresti altrimenti. Non è necessario il QA ragazzo dire "ehi, non si sono preoccupati limiti-checking la funzione XYZ (), vero? Lui non viene a scoprire che errore, perché si trovato un mese fa. Questo è positivo per lui, buono per te, buono per l'azienda e buono per il cliente.
Chiaramente questo è aneddotico, ma ha funzionato a meraviglia per me. Non sono sicuro di poterti fornire fogli di calcolo, ma il mio cliente è felice e questo è l'obiettivo finale.