Qu'est-ce que je perds en adoptant la conception pilotée par les tests ?
N'indiquez que les points négatifs ; n'indiquez pas les avantages écrits à la forme négative.
Si vous voulez faire du "vrai" TDD (lire : tester d'abord avec les étapes rouge, verte, refactor), vous devez aussi commencer à utiliser les mocks/stubs, lorsque vous voulez tester les points d'intégration.
Lorsque vous commencez à utiliser les mocks, après un certain temps, vous voudrez commencer à utiliser l'injection de dépendance (DI) et un conteneur d'inversion de contrôle (IoC). Pour ce faire, vous devez utiliser des interfaces pour tout (qui ont elles-mêmes beaucoup de pièges).
En fin de compte, vous devez écrire beaucoup plus de code que si vous le faites simplement de la "bonne vieille façon". Au lieu d'une simple classe client, vous devez également écrire une interface, une classe fantaisie, une configuration IoC et quelques tests.
Et n'oubliez pas que le code de test doit également être maintenu et entretenu. Les tests doivent être aussi lisibles que tout le reste et il faut du temps pour écrire un bon code.
De nombreux développeurs ne comprennent pas vraiment comment faire tout cela "de la bonne manière". Mais comme tout le monde leur dit que la TDD est la seule vraie façon de développer des logiciels, ils font de leur mieux.
C'est beaucoup plus difficile que ce que l'on pourrait croire. Souvent, les projets réalisés avec TDD se retrouvent avec beaucoup de code que personne ne comprend vraiment. Les tests unitaires testent souvent la mauvaise chose, de la mauvaise manière. Et personne n'est d'accord sur la façon dont un bon test devrait ressembler, pas même les soi-disant gourous.
Tous ces tests rendent beaucoup plus difficile le "changement" (opposé à la refonte) du comportement de votre système et les changements simples deviennent tout simplement trop difficiles et prennent trop de temps.
Si vous lisez la littérature TDD, vous trouverez toujours de très bons exemples, mais souvent, dans les applications réelles, vous devez avoir une interface utilisateur et une base de données. C'est là que la TDD devient vraiment difficile, et la plupart des sources n'offrent pas de bonnes réponses. Et si elles le font, cela implique toujours plus d'abstractions : objets fantaisie, programmation sur une interface, modèles MVC/MVP, etc., ce qui nécessite à nouveau beaucoup de connaissances, et... vous devez écrire encore plus de code.
Alors faites attention... si vous n'avez pas une équipe enthousiaste et au moins un développeur expérimenté qui sait comment écrire de bons tests et qui connaît aussi quelques notions de bonne architecture, vous devez vraiment y réfléchir à deux fois avant de vous lancer dans le TDD.
En utilisant des outils comme Pex & Moles vous pouvez très facilement éviter d'écrire des interfaces pour chaque petite chose. Les taupes vous y aideront énormément.
On dirait une critique des tests unitaires et de la programmation orientée objet, pas de la TDD.
En fait, un **test unitaire** correct - et pas seulement le TDD - nécessite des mocks / stubs. Et programmer contre une interface est souvent une bonne idée, il en va de même pour les patterns. Si vous mélangez l'interface utilisateur et la logique, vous passerez un mauvais moment. Si vous devez tester l'interaction avec la base de données, vous pouvez toujours simuler votre DAO pour les tests unitaires et utiliser la vraie chose pour un test d'intégration.
Plusieurs inconvénients (et je ne prétends pas qu'il n'y a pas d'avantages - surtout lorsqu'il s'agit de rédiger les bases d'un projet - cela permettrait de gagner beaucoup de temps à la fin) :
De nombreux "effets graphiques" seront basés sur la géométrie, qui peut facilement être appliquée aux tests. Sinon, il est basé sur une bibliothèque qui doit être bien testée.
Le point principal (4) est le suivant : tout système qui n'est pas bien défini et qui est susceptible de continuer à changer pour s'adapter à un comportement visuel en évolution, à différentes spécifications d'IA, à des algorithmes comportementaux, etc. entraînera un investissement important en temps dans la définition de tests répétés, puisque nous changeons constamment les résultats de test souhaités.
Lorsque vous arrivez à un point où vous avez un grand nombre de tests, changer le système peut nécessiter de réécrire une partie ou la totalité de vos tests, en fonction de ceux qui ont été invalidés par les changements. Cela peut transformer une modification relativement rapide en une modification qui prend beaucoup de temps.
En outre, vous pourriez commencer à prendre des décisions de conception en vous basant davantage sur le TDD que sur des principes de conception réellement bons. Alors que vous aviez peut-être une solution très simple et facile, impossible à tester comme l'exige le TDD, vous avez maintenant un système beaucoup plus complexe qui est en fait plus sujet aux erreurs.
Cela peut certainement être un problème, mais je constate une différence notable dans la mesure où je suis affecté par ce problème. Tout se résume à "écrire du code testable", je suppose.
Un test unitaire ne teste-t-il pas par définition la plus petite unité de code possible ? Une fonction, une méthode, etc. Puisque les refactorings sont censés être incrémentaux dans une approche TDD, le pourcentage total de votre code de test qui casse devrait être faible pour tout refactoring donné. N'est-ce pas ?
@Allain, c'est la théorie, en pratique les choses sont toujours plus compliquées, surtout quand on travaille en équipe. Il n'y a rien de magique dans le code de test qui le rend automatiquement mieux écrit ou mieux conçu. C'est un problème classique de "qui surveille les surveillants".
Je pense que le plus gros problème pour moi est l'ÉNORME perte de temps qu'il faut pour "s'y mettre". Je n'en suis encore qu'au début de mon voyage dans le domaine de la TDD. blog pour les mises à jour de mes aventures de test si vous êtes intéressés) et j'ai littéralement passé heures pour commencer.
Il faut beaucoup de temps pour mettre son cerveau en "mode test" et écrire du "code testable" est une compétence en soi.
TBH, je suis respectueusement en désaccord avec Commentaires de Jason Cohen sur le fait de rendre des méthodes privées publiques, ce n'est pas de cela qu'il s'agit. Dans ma nouvelle façon de travailler, je n'ai pas fait plus de méthodes publiques qu'auparavant. . Elle implique toutefois des changements architecturaux et vous permet de "brancher à chaud" des modules de code pour faciliter le test de tous les autres éléments. Vous devez no Pour ce faire, il faut rendre les éléments internes de votre code plus accessibles. Sinon, nous sommes de retour à la case départ avec tout ce qui est public, où est l'encapsulation dans tout cela ?
Donc, (IMO) en un mot :
PS : Si vous souhaitez des liens vers des sites positifs, j'ai posé et répondu à plusieurs questions sur ce sujet, consultez mon profil .
Depuis quelques années que je pratique le développement piloté par les tests, je dois dire que les principaux inconvénients sont les suivants :
Le TDD est mieux réalisé en binôme. D'une part, il est difficile de résister à l'envie de simplement écrire l'implémentation lorsque vous SAVOIR comment rédiger un si/seulement déclaration. Mais un binôme vous gardera à la tâche parce que vous le gardez à la tâche. Malheureusement, de nombreuses entreprises/managers ne pensent pas que c'est une bonne utilisation des ressources. Pourquoi payer deux personnes pour écrire une fonctionnalité, alors que j'ai deux fonctionnalités qui doivent être réalisées en même temps ?
Certaines personnes n'ont tout simplement pas la patience d'écrire des tests unitaires. D'autres sont très fiers de leur travail. Ou encore, certains aiment voir des méthodes/fonctions alambiquées déborder du bout de l'écran. La TDD ne convient pas à tout le monde, mais j'aimerais vraiment qu'elle le soit. Cela rendrait la maintenance beaucoup plus facile pour ces pauvres âmes qui héritent du code.
Idéalement, vos tests ne s'interrompent que lorsque vous prenez une mauvaise décision de code. C'est-à-dire que vous pensiez que le système fonctionnait d'une certaine manière, et il s'avère que ce n'est pas le cas. En cassant un test, ou un (petit) ensemble de tests, c'est en fait une bonne nouvelle. Vous savez que exactement comment votre nouveau code va affecter le système. Cependant, si vos tests sont mal écrits, étroitement couplés ou, pire encore, générés ( toux VS Test), alors la maintenance de vos tests peut rapidement devenir une corvée. Et, après qu'un nombre suffisant de tests commence à causer plus de travail que la valeur perçue qu'ils créent, alors les tests seront la première chose à être supprimée lorsque les plannings deviennent comprimés (par exemple, lorsque le temps presse).
Idéalement, encore une fois, si vous adhérez à la méthodologie, votre code sera testé à 100% par défaut. En général, je me retrouve avec une couverture de code supérieure à 90 %. Cela se produit généralement lorsque j'ai une architecture de type template, que la base est testée et que j'essaie de faire des économies et de ne pas tester les personnalisations du template. De plus, j'ai constaté que lorsque je rencontre une nouvelle barrière que je n'avais pas encore rencontrée, j'ai une courbe d'apprentissage pour la tester. J'admets que j'écris quelques lignes de code à l'ancienne, mais j'aime vraiment avoir cette garantie à 100 %. (Je suppose que j'étais un sur-performant à l'école, euh skool).
Cependant, je dirais que les avantages de la TDD l'emportent largement sur les inconvénients, pour la simple raison que si vous parvenez à mettre en place un bon ensemble de tests qui couvrent votre application mais ne sont pas si fragiles qu'un seul changement les casse tous, vous serez en mesure de continuer à ajouter de nouvelles fonctionnalités au 300e jour de votre projet comme vous l'avez fait au premier jour. Ce n'est pas le cas de tous ceux qui essaient la TDD en pensant qu'il s'agit d'une solution miracle à tous leurs codes truffés de bogues, et qui pensent donc que cela ne peut pas fonctionner, point final.
Personnellement, j'ai constaté qu'avec le TDD, j'écris un code plus simple, je passe moins de temps à me demander si une solution de code particulière fonctionnera ou non, et je n'ai pas peur de modifier une ligne de code qui ne répond pas aux critères établis par l'équipe.
Le TDD est une discipline difficile à maîtriser. J'y travaille depuis plusieurs années et j'apprends toujours de nouvelles techniques de test. C'est un énorme investissement en temps au départ, mais, à long terme, votre durabilité sera bien plus grande que si vous n'aviez pas de tests unitaires automatisés. Maintenant, si seulement mes patrons pouvaient comprendre cela.
+1 pour le problème de la vente :) Je suis actuellement dans une nouvelle entreprise et je réfléchis à la manière de créer une culture qui permettrait aux compétences de se répandre librement.
Comme vous, je considère que certaines sociétés de conseil profitent de la programmation par paire et du TDD uniquement pour obtenir plus d'argent de leurs clients. Il est assez décevant de voir comment ces clients paient pour des idées qui semblent raisonnables à première vue, comme le fait que deux personnes pensent mieux que deux ou que TDD garantit que chaque ligne de code est testée, mais qui ne sont en fait que des excuses pour faire payer plus cher un client pour quelque chose qu'une seule personne peut faire.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
J'ai ajouté une réponse indiquant que le BDD peut atténuer certains de ces aspects négatifs. Je vous invite à tenir compte de ce facteur lorsque vous recueillez vos commentaires négatifs, car certains d'entre eux peuvent être éliminés et ne plus être considérés comme négatifs.
25 votes
Pour clarifier, je ne suis ni contre ni pour. J'essaie de prendre une décision éclairée sur la question, mais la plupart des personnes qui prônent le TDD ne comprennent pas, ou ne veulent pas admettre les aspects négatifs.
1 votes
Le titre mentionne "Test Driven Development", mais le corps de la question mentionne "Test Driven Design". Sur lequel des deux cette question porte-t-elle ? Il existe des différences importantes, mais subtiles, entre les deux. La conception pilotée par les tests consiste à laisser les tests guider la conception du logiciel. Le développement piloté par les tests est généralement associé à l'écriture de tests avant le code de production (mais sans nécessairement laisser les tests influencer la conception).
3 votes
TDD est une cage qui retient la créativité du développeur.
13 votes
S'il te plaît, arrête de fermer les questions importantes, DJESUS.