Comment concevoir des systèmes complexes avec TDD ?

Question

Similaire à Le TDD signifie-t-il qu'il ne faut pas penser à la conception des classes ? J'ai du mal à penser à la place de l'étape traditionnelle de "conception" dans le TDD.

Selon le Bowling Game Kata (la version "conversation", dont le lien m'échappe pour le moment), le TDD semble ignorer les décisions de conception prises dès le début (rejet de l'objet "frame", objet "roll", etc.). Je peux voir dans cet exemple que c'est une bonne idée de suivre les tests et d'ignorer vos idées initiales de conception, mais dans les projets plus importants ou ceux où vous voulez laisser une ouverture pour l'expansion / personnalisation, ne serait-il pas mieux de mettre des choses dans que vous n'avez pas un test pour ou n'avez pas un besoin immédiat afin d'éviter des réécritures coûteuses en temps plus tard ?

En bref, à quel point la conception est-elle excessive dans le cadre du TDD, et à quel point dois-je suivre cette conception lorsque j'écris les tests et le code pour les faire passer (en ignorant ma conception pour ne me soucier que de faire passer les tests) ?

Ou bien je m'inquiète pour rien, et le code écrit simplement pour suivre les tests est no (en pratique) difficile à réécrire ou à remanier si vous êtes coincé ? Ou bien, est-ce que je passe à côté de l'essentiel et que je devrais plutôt être en attendant de réécrire des parties du code lorsque je viens tester une nouvelle section de la fonctionnalité ?

Answer 1

Je baserais vos tests sur votre conception initiale. À bien des égards, le TDD est un processus de découverte. Vous pouvez vous attendre à confirmer vos choix de conception initiaux ou à découvrir que vous pouvez faire de meilleurs choix. Faites autant de conception initiale que vous le souhaitez. Certains aiment voler de leurs propres ailes en faisant de la conception de haut niveau et en utilisant le TDD pour étoffer la conception. D'autres préfèrent que tout soit d'abord couché sur le papier.

Une partie de la TDD est la refactorisation.

Answer 2

Il y a quelque chose à dire sur la "conception de grands systèmes complexes" qui ne devrait pas être associée à la DDT. notamment lorsque TDD est interprété comme "Test Driven Design" et non "Test Driven Development".

Dans le contexte du développement, l'utilisation de la méthodologie TDD vous permettra de vous assurer que vous écrivez testable un code qui offre tous les avantages cités à propos du TDD (détection précoce des bogues, ratio élevé de couverture du code par les tests, refactoring futur plus facile, etc. etc.)

Mais dans la "conception" de grands systèmes complexes, la TDD ne répond pas particulièrement aux préoccupations suivantes, qui sont inhérentes à l'architecture du système

1. (Ingénierie pour) la performance
2. Sécurité
3. Évolutivité
4. Disponibilité
5. (et toutes les autres "ilités")

(c'est-à-dire que toutes les préoccupations ci-dessus n'émergent pas comme par magie de la recette "écrire d'abord un scénario de test qui échoue, puis l'implémentation qui fonctionne, refactoriser - faire mousser, rincer, répéter...").

• Pour ces derniers, vous devrez aborder le problème en dressant un tableau blanc des détails de haut niveau puis de bas niveau d'un système par rapport aux contraintes imposées par les exigences et l'espace du problème.

• Certaines des considérations ci-dessus entrent en concurrence les unes avec les autres et nécessitent des compromis minutieux qui n'émergent pas de l'écriture de nombreux tests unitaires.

• Une fois que les composants clés et leurs responsabilités sont définis et compris, la DRT peut être utilisée dans le la mise en œuvre de ces composants . Le processus de refactoring et de révision/amélioration d'améliorer votre code garantira que les détails de conception de bas niveau de ces de bas niveau de ces composants soient bien conçus.

Je n'ai encore jamais rencontré un logiciel d'une complexité significative (par exemple, un compilateur, une base de données, un système d'exploitation) qui ait été réalisé en un temps record. Pilotage par les tests Design le style. L'article de blog suivant traite très bien de ce point ( Compilateurs, TDD, Maîtrise )

Vérifiez également les points suivants vidéos sur l'architecture ce qui ajoute beaucoup de bon sens au processus de réflexion.

Answer 3

Commencez par une idée de conception approximative, choisissez un premier test et commencez à coder, en passant de test en test, laissant émerger la conception, similaire ou non à la conception initiale. L'importance de la conception initiale dépend de la complexité du problème.

Il faut être attentif, écouter et renifler le code, pour détecter les possibilités de remaniement et les odeurs de code.

En suivant strictement le TDD et le Principes SOLIDES apportera un code propre, testable et flexible, afin qu'il puisse être facilement remanié, en s'appuyant sur les tests unitaires comme échafaudage pour éviter la régression.

Answer 4

J'ai trouvé trois façons de faire de la conception avec TDD :

• Permettre à la conception d'émerger naturellement au fur et à mesure que la duplication et la complexité sont éliminées.
• Créez un design parfait dès le départ, en utilisant des objets fantaisie combinés au principe de responsabilité unique.
• Soyez pragmatique à ce sujet.

Le pragmatisme semble être le meilleur choix la plupart du temps, alors voici ce que je fais. Si je sais qu'un modèle particulier conviendra très bien à mon problème (par exemple, MVC), j'irai directement vers les mocks et supposerai qu'il fonctionne. Sinon, si le design est moins clair, je le laisse émerger.

Le point d'intersection où je ressens le besoin de remanier une conception émergente est le point où elle cesse d'être facile à modifier. Si un morceau de code n'est pas parfaitement conçu, mais qu'un autre développeur qui le rencontre pourrait facilement le remanier lui-même, c'est suffisant. Si le code devient si complexe qu'il n'est plus évident pour un autre développeur, il est temps de le remanier.

J'aime les options réelles, et remanier quelque chose à la perfection me donne l'impression de m'engager dans la conception sans en avoir vraiment besoin. Je remanie plutôt quelque chose pour qu'il soit "suffisamment bon" ; de cette façon, si ma conception s'avère être mauvaise, je n'ai pas perdu mon temps. Partez du principe que votre conception sera mauvaise si vous ne l'avez jamais utilisée auparavant dans un contexte similaire.

Cela me permet également de sortir mon code beaucoup plus rapidement que s'il était parfait. Cela dit, ce sont mes tentatives pour rendre le code parfait qui m'ont appris où était la limite !