Pożądane jest usunięcie, b()gdy nie będzie już używane, z tego samego powodu, dla którego pożądane jest, aby nie dodawać nieużywanych funkcji w pierwszej kolejności. Niezależnie od tego, czy nazywasz to „czytelnością”, czy czymś innym, wszystko inne jest równe, jest to ulepszenie kodu, które nie zawiera niczego, do czego nie ma pożytku. Ze względu na co najmniej jeden konkretny środek, dzięki któremu lepiej go nie mieć, usunięcie go gwarantuje, że jego przyszłe koszty utrzymania po tej zmianie wynoszą zero!
Nie znalazłem żadnej specjalnej techniki, która byłaby potrzebna do faktycznego usunięcia go za pomocą jego testów, ponieważ każdej myśli o zamianie na b()coś nowego musi oczywiście towarzyszyć rozpatrzenie całego aktualnie wywoływanego kodu b(), a testy stanowią podzbiór „całego kodu „.
Argumentacja, która ogólnie dla mnie działa, polega na tym, że w momencie, w którym zauważyłem, że f()stało się to b()przestarzałe, dlatego b()powinienem być przynajmniej przestarzały, a ja szukam wszystkich połączeń b()z zamiarem zastąpienia ich wezwaniami do f(), ja rozważ również kod testowy . W szczególności, jeśli b()nie jest już wymagany, mogę i powinienem usunąć jego testy jednostkowe.
Masz całkowitą rację, że nic nie zmusza mnie do zauważenia, że b()nie jest już wymagane. Jest to kwestia umiejętności (i, jak mówi Slim, raportów dotyczących pokrycia kodu w testach wyższego poziomu). Jeśli odwołują się tylko testy jednostkowe, a nie testy funkcjonalne, b()mogę być ostrożnie optymistyczny, że nie jest on częścią żadnego opublikowanego interfejsu, a zatem usunięcie go nie jest przełomową zmianą dla żadnego kodu, który nie jest pod moją bezpośrednią kontrolą.
Cykl czerwony / zielony / refaktor nie wspomina wyraźnie o usunięciu testów. Co więcej, usunięcie b()narusza zasadę otwartego / zamkniętego, ponieważ oczywiście twój komponent jest otwarty na modyfikacje. Więc jeśli chcesz myśleć o tym kroku jako o czymś poza prostym TDD, śmiało. Na przykład możesz mieć jakiś proces deklarowania testu jako „zły”, który można zastosować w tym przypadku, aby usunąć test, ponieważ testuje on coś, czego nie powinno być (niepotrzebna funkcja b()).
Myślę, że w praktyce większość ludzi prawdopodobnie dopuszcza przeprowadzenie pewnej ilości przeprojektowania wraz z cyklem czerwony / zielony / refaktor, lub uważają usunięcie zbędnych testów jednostkowych za ważną część „refaktora”, choć ściśle mówiąc to nie jest refaktoryzacja. Twój zespół może zdecydować, ile dramatu i formalności powinno być zaangażowanych w uzasadnienie tej decyzji.
W każdym razie, jeśli b()było to ważne, byłyby testy funkcjonalne, które nie zostałyby lekko usunięte, ale już powiedziałeś, że są tylko testy jednostkowe. Jeśli nie rozróżniasz odpowiednio testów jednostkowych (zapisanych w bieżącym projekcie wewnętrznym kodu, który zmieniłeś) i testów funkcjonalnych (napisanych w opublikowanych interfejsach, których być może nie chcesz zmieniać), musisz być bardziej ostrożny na temat usuwania testów jednostkowych.