Notre équipe se demande actuellement si la modification de la conception du code pour permettre les tests unitaires est une odeur de code, ou dans quelle mesure cela peut être fait sans être une odeur de code. Cela est dû au fait que nous commençons tout juste à mettre en place des pratiques qui sont présentes dans à peu près toutes les autres sociétés de développement de logiciels.
Plus précisément, nous aurons un service API Web qui sera très mince. Sa principale responsabilité consistera à organiser les requêtes / réponses Web et à appeler une API sous-jacente contenant la logique métier.
Un exemple est que nous prévoyons de créer une usine qui renverra un type de méthode d'authentification. Nous n'avons pas besoin qu'il hérite d'une interface car nous ne prévoyons pas qu'il s'agira jamais d'un type autre que concret. Cependant, pour tester un peu le service API Web, nous devrons nous moquer de cette usine.
Cela signifie essentiellement que nous concevons la classe de contrôleur API Web pour accepter DI (via son constructeur ou son séparateur), ce qui signifie que nous concevons une partie du contrôleur simplement pour permettre à DI et implémenter une interface dont nous n'avons pas autrement besoin, ou nous utilisons Un framework tiers, comme Ninject, évite de devoir concevoir le contrôleur de cette manière, mais il reste à créer une interface.
Certains membres de l'équipe semblent réticents à concevoir du code uniquement pour tester. Il me semble qu’il faut trouver un compromis pour espérer passer le test unitaire, mais je ne sais pas comment répondre à leurs préoccupations.
Soyons clairs: il s’agit d’un tout nouveau projet. Il ne s’agit donc pas vraiment de modifier le code pour permettre les tests unitaires; il s'agit de concevoir le code que nous allons écrire pour être unitaire testable.