È preferibile rimuovere b() una volta che non è più utilizzato, per lo stesso motivo per cui è preferibile non aggiungere funzioni non utilizzate in primo luogo. Che tu lo chiami "leggibilità" o qualcos'altro, a parità di tutti gli altri è un miglioramento del codice che non contiene nulla per cui non serve. Per avere almeno una misura specifica con la quale è meglio non averlo, rimuoverlo garantisce che il suo costo di mantenimento futuro dopo tale modifica è pari a zero!
Non ho trovato alcuna tecnica speciale necessaria per rimuoverla effettivamente con i suoi test, dal momento che qualsiasi idea di sostituire b() con qualcosa di nuovo deve ovviamente essere accompagnata da una considerazione di tutto il codice che attualmente chiama b() , e i test sono un sottoinsieme di "tutto il codice".
La linea di ragionamento che generalmente funziona per me è quella al punto in cui ho notato che f() ha reso b() obsoleto, quindi b() dovrebbe essere almeno deprecato e sto cercando di trovare tutte le chiamate a b() con l'intento di sostituirli con chiamate a f() , Considero anche il codice di prova . In particolare, se b() non è più necessario, posso e dovrei rimuovere i suoi test unitari.
Hai ragione a dire che mi mi impone di notare che b() non è più necessario. Questa è una questione di abilità (e, come dice slim, rapporti sulla copertura del codice nei test di livello superiore). Se solo i test unitari, e nessun test funzionale, si riferiscono a b() , allora posso essere cautamente ottimista sul fatto che non fa parte di alcuna interfaccia pubblicata e quindi rimuoverlo non è un cambiamento di rottura per qualsiasi codice non sotto il mio controllo diretto.
Il ciclo rosso / verde / refactor non menziona esplicitamente la rimozione dei test. Inoltre, la rimozione di b() viola il principio di apertura / chiusura poiché chiaramente il tuo componente è aperto per la modifica. Quindi, se vuoi pensare a questo passaggio come qualcosa che si trova al di fuori del semplice TDD, vai avanti. Ad esempio, potresti avere qualche processo per dichiarare un test "cattivo", che può essere applicato in questo caso per rimuovere il test sulla base del fatto che prova per qualcosa che non dovrebbe essere lì (la funzione non necessaria b() ).
Penso che in pratica la maggior parte delle persone permetta di effettuare una certa riprogettazione con un ciclo rosso / verde / refactoring, o ritengono che rimuovere i test unitari ridondanti sia una parte valida di un "refactoring" anche se in senso stretto non si tratta di refactoring. La tua squadra può decidere quanto dramma e documenti dovrebbero essere coinvolti nel giustificare questa decisione.
Ad ogni modo, se b() era importante, c'erano test funzionali per questo, e quelli non sarebbero stati rimossi leggermente, ma hai già detto che ci sono solo test unitari. Se non si distingue correttamente tra test unitari (scritti nella progettazione interna corrente del codice, che è stata modificata) e test funzionali (scritti su interfacce pubblicate, che forse non si desidera modificare), è necessario essere più cauti sulla rimozione dei test unitari.