Qual è il valore della scrittura di ulteriori test unitari quando si riprogramma una funzione più grande in funzioni più piccole?

Presumo che tu abbia già test unitari che coprono il comportamento di do_everything() ? Se hai rotto turn_twizzles() ecc. Come metodi privati, non hai modificato alcun comportamento esterno, quindi non devi modificare alcun test.

Se tuttavia turn_twizzles() è reso pubblico, hai introdotto una nuova funzionalità (osservata al di fuori della classe), quindi sarebbe utile testarla.

Dipende. Per essere più precisi, dipende da

• la complessità della funzione originale (se fosse molto complessa, testare ciascuna parte da sola ripagherà)
• la complessità delle funzioni più piccole (se sono parti complesse da sole, testarle singolarmente porteranno a test più precisi e un rilevamento più preciso delle cause alla radice in caso di un difetto)
• i test unitari esistenti (se già producono una copertura sufficiente per tutte quelle "parti", allora probabilmente è meno utile scrivere test individuali)
• se vuoi mantenere quelle "funzioni di implementazione" più piccole delle funzioni originali, o meno (per la prima, scrivere test di unità per le funzioni più piccole sarebbe controproducente per questo obiettivo).

Specialmente quando quelle "funzioni più piccole" non sono così banali come nel tuo esempio, ma avranno una lista più o meno complessa di parametri di input, può diventare davvero difficile produrre test di unità sufficienti per la tua funzione originale per garantire il più piccolo le funzioni sono testate con tutte le combinazioni di input "interessanti". Questo sarebbe un chiaro segno per scrivere test unitari specifici anche per le funzioni più piccole.

Quindi, non c'è un chiaro "sì" o "no" a questa domanda, è un trade-off che devi decidere per caso.

Se turn_twizzles , push_buttons e move_mountain sono pubblici e richiamati da un altro codice, penso che sia importante rifattorizzare i test per verificare singolarmente queste funzioni.

Sfortunatamente dopo il refactor hai un problema: al test unitario do_everything devi essere in grado di simulare turn_twizzles , push_buttons e move_mountain . Scrivere test per do_everything senza prendere in giro le dipendenze sarà un test di integrazione - non necessariamente una cosa negativa a seconda del piano di test, ma non ci sarà molto vantaggio perché stai già testando individualmente le tre funzioni più piccole. Questo potrebbe essere il momento giusto per riprogettare questo componente e collaborare con altri oggetti per eseguire tutto il lavoro di do_everything .

Se turn_twizzles , push_buttons e move_mountain non vengono chiamati esternamente, devono essere contrassegnati come privati e non è consigliabile testarli separatamente da do_everything . Questo perché da una prospettiva esterna, do_everything sarebbe l'unità più piccola (perché gli altri sono inaccessibili). Vedi anche questa risposta su come suddividere i metodi usando metodi privati.

No. I test di unità extra sono più precisi. Se move_mountain fallisce, fallisce un singolo test che dice in modo molto specifico cosa è andato storto.

Questa precisione riduce il tempo di debug, che è prezioso. Inoltre, poiché il test è più mirato, dovrebbe essere più veloce da eseguire rispetto a testare la stessa funzionalità tramite la funzione completa, fornendo un feedback più rapido, che è prezioso.