pour autant que je sache, la plupart des gens semblent convenir que les méthodes privées ne doivent pas être testées directement, mais plutôt par le biais de méthodes publiques. Je peux comprendre leur point de vue, mais cela me pose quelques problèmes lorsque j'essaie de suivre les "Trois lois du TDD" et d’utiliser le cycle "Rouge - vert - refactor". Je pense que cela s'explique mieux par un exemple:
Pour le moment, j'ai besoin d'un programme capable de lire un fichier (contenant des données séparées par des tabulations) et de filtrer toutes les colonnes contenant des données non numériques. Je suppose qu'il existe probablement déjà quelques outils simples pour le faire, mais j'ai décidé de le mettre en œuvre moi-même, principalement parce que je pensais que ce pourrait être un projet intéressant et propre pour moi de m'entraîner avec TDD.
Alors, premièrement, je "mets le chapeau rouge", c’est-à-dire qu’il me faut un test qui échoue. J'ai pensé qu'il me faudrait une méthode qui trouve tous les champs non numériques dans une ligne. Donc, j’écris un test simple, bien sûr, la compilation n’est pas immédiate, alors j’écris la fonction elle-même, et après quelques cycles (rouge / vert), j’ai une fonction fonctionnelle et un test complet.
Ensuite, je continue avec une fonction, "rassemblerNonNumericColumns" qui lit le fichier, une ligne à la fois, et appelle ma fonction "findNonNumericFields" sur chaque ligne pour rassembler toutes les colonnes qui doivent éventuellement être supprimées. Un couple de cycles rouge-vert, et j'ai terminé, d'avoir à nouveau une fonction de travail et un test complet.
Maintenant, je pense que je devrais refactoriser. Étant donné que ma méthode "findNonNumericFields" a été conçue uniquement parce que je pensais en avoir besoin lors de la mise en oeuvre de "collecteNonNumericColumns", il me semble raisonnable de laisser "findNonNumericFields" privé. Cependant, cela romprait mes premiers tests, car ils n'auraient plus accès à la méthode qu'ils testaient.
Donc, je me retrouve avec une méthode privée, et une suite de tests qui le teste. Étant donné que tant de personnes conseillent de ne pas tester les méthodes privées, j'ai l'impression que je me suis retrouvé dans un coin. Mais où ai-je échoué?
Je suppose que j'aurais pu commencer à un niveau supérieur, en écrivant un test qui teste ce qui deviendra finalement ma méthode publique (c'est-à-dire, findAndFilterOutAllNonNumericalColumns), mais cela semble un peu contraire à l'intérêt de TDD (du moins d'après Oncle Bob) : Que vous devez commuter constamment entre les tests d’écriture et le code de production et que, à tout moment, tous vos tests fonctionnent à la dernière minute. Parce que si je commence par écrire un test pour une méthode publique, il faudra plusieurs minutes (ou même plusieurs heures, voire plusieurs jours dans des cas très complexes) pour obtenir tous les détails des méthodes privées afin que le test teste le public la méthode passe.
Alors que faire? TDD (avec le cycle rapide rouge-vert-refactor) est-il tout simplement incompatible avec les méthodes privées? Ou y a-t-il un défaut dans ma conception?
private
s'il était logique de le faire.