Quels modèles de conception à créer avant TDD?

Question

Résumé:

Quels modèles et diagrammes avez-vous inclus et/ou livrés dans votre TD -design vs -development, et pourquoi?

Détails:

Nouveau projet 4-développeur, dans un magasin où nous faisons progressivement des progrès dans la gestion d'obtenir leur diplôme de « acheter » à « action » dans l'adoption TDD/attente. Je suis (un développeur) voulant conception axée sur le test pour le nouveau projet. Certains modèles et diagrammes sont créés (ceux-ci complèteront les maquettes d'interface utilisateur pour transmettre la conception détaillée au client avant le début du développement significatif). Donc, étant donné ce contexte, quels modèles et diagrammes considéreriez-vous raisonnables? Le livrable de ce projet est une webapp qui n'est ni triviale ni trop complexe. Nous avons un document d'exigences (vague parfois, mais un bon début pour écrire des tests contre). Mais l'expérience de TDD que j'ai eue jusqu'à présent (un projet à très faible défaut que je possédais en solo avec TDD, et un peu de création de tests de pairs en maturation) me laisse envie de continuer à côté du test -drive conception. Le processus de création des modèles/diagrammes (on dirait que nous allons livrer des modèles de classe et quelques cas d'utilisation de haut niveau et des diagrammes de séquence) ne semble pas donner aux concepteurs (développeurs) l'idée que TDD ne serait pas , et ils sont assez techniques/complexes que je crains que n'importe quel non-développeur les ignorera effectivement (lire: les accepter aveuglément) quand ils leur seront présentés. Où tracez-vous la limite entre l'inclusion et l'exclusion des modèles et des diagrammes dans TD -design vs -development?

Answer 1

Il ya un dicton militaire: "Les plans ne sont rien, la planification est tout." Si les diagrammes créent une communication utile avec le client sur la manière dont la conception du système est envisagée et sur les domaines qu'il est censé englober et comment il va se dérouler, la pratique de la planification en vaut la peine.

Ce que TDD suggère est que cette conception soit sujette à changement lorsque le caoutchouc rencontre la route lors du codage. La question est de savoir à quel point il sera important de communiquer ces changements lorsqu'ils surviendront. Mais dans les architectures complexes, une planification préalable est précieuse, même dans le contexte de TDD, tant que vous réalisez que c'est de la planification et non des plans fixes. La réflexion qui a mené à la conception originale est quelque chose qui peut être référencé pour comprendre ce que le TDD a découvert et comment les choses doivent changer pour s'adapter. Par la suite, vous pouvez regarder en arrière et indiquer à la direction à quel point le produit final différait de la planification initiale et voir ce qui a changé, et peut-être être en mesure de souligner que la conception initiale n'a pas contribué autant qu'ils pensaient.

Answer 2

Personnellement, je ne pense pas que ma documentation de conception changerait avec TDD par rapport à un autre mode de développement. Je commencerais par les cas d'utilisation de haut niveau et je travaillerais lentement jusqu'à ce que j'aie des documents d'utilisation fonctionnelle très spécifiques (ainsi que toute la documentation d'accompagnement comme les diagrammes de classes, les diagrammes d'activités, etc.).

Une fois que vous avez les White Box Cas d'utilisation ... vous devez savoir deux choses:

1. Qu'est-ce que le code devrait faire.
2. Ce que le code NE DEVRAIT PAS faire.

Vous pouvez ensuite coder votre application pour faire ce qu'elle devrait ... et coder vos tests pour vous assurer qu'elle ne fait pas ce qu'elle ne devrait pas faire.

Answer 3

TDD ne doit pas s'appuyer sur des modèles et des diagrammes fixes, sinon vous limitez ou cassez son processus de refactoring. Donc, si vous avez vraiment besoin de modèles, j'utiliserais des diagrammes de haut niveau comme des diagrammes de séquence pour illustrer la navigation de votre application (qui ont moins de chance de changer que votre diagramme de classe).

Un autre point est que les artefacts de haut niveau peuvent aider votre client à créer des routines de test pour valider les fonctions de votre système.

Answer 4

Puisque vous avez besoin de générer des documents que vous ne pensez pas que quelqu'un se soucie vraiment, vous devriez penser à ce qui va vraiment aider votre équipe de développement:

• En mode Domain Driven Design, créer une documents qui montrent vos objets de modèle fondamentaux. Faites ce que vous pouvez pour obtenir des concepts peu clairs et une terminologie convenue. Ces deux problèmes causent «gaspillage» dans le cycle de développement, que ce soit TDD ou non. Discuter de l'endroit où les risques les plus importants sont associés aux projets. Y a-t-il des diagrammes, et les discussions qui les précéderont et les suivront, qui peuvent aider à atténuer ces risques?

• (J'ai fait celui-ci) Concevez un ensemble de base de "données d'appareils" pour votre test. Quel est l'ensemble minimal de données qui capture toutes les relations et tous les cas importants? Ceci est un artefact non traditionnel, donc vous ne l'avez probablement pas déjà. Mais il faudra du temps pour se développer. Une fois que vous l'aurez, cela accélérera l'écriture de votre test, et cela peut avoir l'effet secondaire d'être un document de communication utile. J'ai fait une mini-affiche de nos données sur notre dernier projet pour faciliter les tests d'écriture.