Il est souhaitable de supprimer b()une fois qu'il n'est plus utilisé, pour la même raison qu'il est souhaitable de ne pas ajouter de fonctions inutilisées en premier lieu. Que vous l'appeliez "lisibilité" ou autre chose, toutes choses étant égales par ailleurs, c'est une amélioration du code qu'il ne contient rien pour lequel il ne sert à rien. Pour avoir au moins une mesure spécifique par laquelle il vaut mieux ne pas l'avoir, sa suppression garantit que son coût de maintenance futur après ce changement est nul!
Je n'ai trouvé aucune technique spéciale pour le supprimer avec ses tests, car toute idée de remplacement b()par quelque chose de nouveau doit bien sûr être accompagnée d'une considération de tout le code en cours d'appel b(), et les tests sont un sous-ensemble de "tout le code" ".
Le raisonnement qui fonctionne généralement pour moi est qu'au moment où je remarque que cela f()est devenu b()obsolète, il b()devrait donc être au moins obsolète, et je cherche à trouver tous les appels à b()dans l'intention de les remplacer par des appels à f(), je considérez également le code de test . Plus précisément, si ce b()n'est plus nécessaire, je peux et je dois supprimer ses tests unitaires.
Vous avez tout à fait raison de dire que rien ne m'oblige à remarquer que ce b()n'est plus nécessaire. C'est une question de compétence (et, comme le dit Slim, les rapports de couverture de code sur les tests de niveau supérieur). Si seuls des tests unitaires, et aucun test fonctionnel, se réfèrent à b(), alors je peux être prudemment optimiste que cela ne fait partie d'aucune interface publiée et donc le supprimer n'est pas un changement de rupture pour tout code qui n'est pas sous mon contrôle direct.
Le cycle rouge / vert / refactor ne mentionne pas explicitement la suppression des tests. En outre, la suppression b()viole le principe ouvert / fermé car il est clair que votre composant est ouvert à modification. Donc, si vous voulez considérer cette étape comme quelque chose en dehors du simple TDD, allez-y. Par exemple, vous pouvez avoir un processus pour déclarer un test "mauvais", qui peut être appliqué dans ce cas pour supprimer le test au motif qu'il teste quelque chose qui ne devrait pas être là (la fonction inutile b()).
Je pense que dans la pratique, la plupart des gens autorisent probablement une certaine refonte avec un cycle rouge / vert / refactor, ou ils considèrent la suppression des tests unitaires redondants comme une partie valide d'un "refactor", même si à proprement parler ce n'est pas du refactoring. Votre équipe peut décider de la quantité de pièces de théâtre et de paperasse à impliquer pour justifier cette décision.
Quoi qu'il en soit, si b()c'était important, il y avait des tests fonctionnels pour cela, et ceux-ci ne seraient pas supprimés à la légère, mais vous avez déjà dit qu'il n'y avait que des tests unitaires. Si vous ne faites pas correctement la distinction entre les tests unitaires (écrits sur la conception interne actuelle du code, que vous avez modifiée) et les tests fonctionnels (écrits sur des interfaces publiées, que vous ne voulez peut-être pas modifier), alors vous devez être plus prudent. sur la suppression des tests unitaires.