È preferibile rimuoverlo b()quando non viene più utilizzato, per lo stesso motivo per cui è preferibile non aggiungere funzioni non utilizzate in primo luogo. Sia che tu lo chiami "leggibilità" o qualcos'altro, a parità di condizioni è un miglioramento del codice che non contiene nulla per cui non è utile. Per avere almeno una misura specifica con la quale è meglio non averla, rimuoverla garantisce che i suoi futuri costi di manutenzione dopo quella modifica siano pari a zero!
Non ho trovato alcuna tecnica speciale necessaria per rimuoverlo effettivamente con i suoi test, dal momento che ogni pensiero di sostituirlo b()con qualcosa di nuovo deve ovviamente essere accompagnato da una considerazione di tutto il codice attualmente chiamato b(), e i test sono un sottoinsieme di "tutto il codice ".
Il ragionamento che generalmente funziona per me è che nel momento in cui noto che f()è diventato b()obsoleto, quindi b()dovrebbe essere almeno deprecato, e sto cercando di trovare tutte le chiamate b()con l'intenzione di sostituirle con chiamate a f(), I considerare anche il codice di prova . In particolare, se b()non è più necessario, allora posso e dovrei rimuovere i suoi test unitari.
Hai perfettamente ragione sul fatto che nulla mi costringe a notare che b()non è più necessario. Questa è una questione di abilità (e, come dice slim, riporta rapporti di copertura del codice su test di livello superiore). Se si riferiscono solo a test unitari e nessun test funzionale, b()posso essere cautamente ottimista sul fatto che non fa parte di alcuna interfaccia pubblicata e quindi rimuoverlo non è una modifica sostanziale per qualsiasi codice non sotto il mio controllo diretto.
Il ciclo rosso / verde / refactor non menziona esplicitamente la rimozione dei test. Inoltre, la rimozione b()viola il principio aperto / chiuso poiché chiaramente il componente è aperto per la modifica. Quindi, se vuoi pensare a questo passaggio come qualcosa al di fuori del semplice TDD, vai avanti. Ad esempio, potresti avere un processo per dichiarare "cattivo" un test, che può essere applicato in questo caso per rimuovere il test in base al test per qualcosa che non dovrebbe essere lì (la funzione non necessaria b()).
Penso che in pratica la maggior parte delle persone probabilmente consenta di eseguire una certa quantità di riprogettazione insieme a un ciclo rosso / verde / refattore, o considerano la rimozione di test unitari ridondanti una parte valida di un "refattore" anche se in senso stretto non è refactoring. Il tuo team può decidere quanto dramma e scartoffie dovrebbero essere coinvolti nel giustificare questa decisione.
Ad ogni modo, se b()fosse importante, ci sarebbero test funzionali per esso, e quelli non verrebbero rimossi alla leggera, ma hai già detto che ci sono solo test unitari. Se non si distingue correttamente tra unit test (scritti nell'attuale design interno del codice, che è stato modificato) e test funzionali (scritti in interfacce pubblicate, che forse non si desidera modificare), è necessario essere più cauti sulla rimozione dei test unitari.