Желательно удалить, как b()только он больше не используется, по той же причине, по которой желательно не добавлять неиспользуемые функции. Называете ли вы это «читабельностью» или чем-то еще, при прочих равных это улучшение кода, в котором нет ничего, что было бы бесполезно. Ради того, чтобы иметь хотя бы одну конкретную меру, по которой лучше ее не иметь, удаление ее гарантирует, что ее будущие затраты на обслуживание после этого изменения будут равны нулю!
Я не нашел какой-либо специальной техники, необходимой для фактического удаления ее с помощью тестов, поскольку любая мысль о замене b()чем-то новым, конечно, должна сопровождаться рассмотрением всего кода, вызываемого в данный момент b(), а тесты являются подмножеством «всего кода». ».
Линия рассуждений, которая обычно работает для меня, заключается в том, что в тот момент, когда я замечаю, что f()оно b()устарело, следовательно, b()должно быть, по крайней мере, устарело, и я ищу, чтобы найти все вызовы b()с намерением заменить их вызовами f(), я рассмотрим также тестовый код . В частности, если b()больше не требуется, я могу и должен удалить его модульные тесты.
Вы совершенно правы, что ничто не заставляет меня замечать, что b()больше не требуется. Это вопрос мастерства (и, как говорит Слим, отчеты о покрытии кода в высокоуровневых тестах). Если ссылаться только на модульные тесты, а не на функциональные тесты, b()то я могу быть осторожно оптимистичен в том, что он не является частью какого-либо опубликованного интерфейса, и поэтому его удаление не является критическим изменением для любого кода, не находящегося под моим непосредственным контролем.
Цикл красный / зеленый / рефактор явно не упоминает удаление тестов. Кроме того, удаление b()нарушает открытый / закрытый принцип , так как очевидно , ваш компонент является открытым для модификации. Так что если вы хотите думать об этом шаге как о чем-то, что выходит за рамки простого TDD, продолжайте. Например, у вас может быть какой-то процесс для объявления теста «плохим», который можно применить в этом случае, чтобы удалить тест на том основании, что он проверяет что-то, чего не должно быть (ненужная функция b()).
Я думаю, что на практике большинство людей, вероятно, допускают определенное количество редизайна, выполняемого вместе с циклом красный / зеленый / рефакторинг, или считают, что удаление избыточных модульных тестов является допустимой частью «рефактора», даже если строго говоря это не рефакторинг. Ваша команда может решить, сколько драмы и документов должно быть вовлечено в обоснование этого решения.
В любом случае, если бы это b()было важно, то были бы функциональные тесты для него, и они не были бы легко удалены, но вы уже сказали, что есть только модульные тесты. Если вы неправильно различаете модульные тесты (записанные в текущем внутреннем проекте кода, которые вы изменили) и функциональные тесты (написанные для опубликованных интерфейсов, которые, возможно, вы не хотите менять), вам нужно быть более осторожным о снятии юнит-тестов.