Quel est le rôle d'un architecte logiciel dans le processus de développement piloté par les tests?

10

Si je comprends bien, le développement piloté par les tests consiste à écrire des tests pour définir les spécifications du programme (vous pouvez me corriger si je me trompe).

S'il y a quelqu'un responsable de la rédaction des spécifications (y compris une API publique) pour le logiciel (appelons-le l'architecte logiciel), cela signifie-t-il que l'architecte logiciel doit écrire tous les tests?

Ou l'architecte logiciel écrit-il les spécifications, puis les remet-il aux développeurs pour qu'ils écrivent les tests?

Ou autorisez-vous les spécifications à croître de manière organique en permettant à tous les développeurs d'écrire leurs propres tests et d'oublier d'avoir un architecte logiciel?

architecture tdd Robert Harvey
la source
Il y a un débat sur english.se sur ce que vous entendez par "grandir organiquement" - english.stackexchange.com/questions/17853/… - voulez-vous confirmer :)
JoseK
@Jose: La dernière phrase de mon PO est censée être légèrement ironique, car il me semble évident qu'un programme doit toujours avoir des spécifications détaillées d'un client. Mais les clients ne savent pas toujours exactement ce qu'ils veulent, c'est pourquoi des processus de développement de logiciels itératifs existent. Voir ici pour plus d'informations sur la métaphore du «logiciel en pleine croissance».
Robert Harvey

Réponses:

5
Le développement piloté par les tests consiste à écrire des tests pour définir les spécifications du programme

Vous n'écrivez pas de tests pour définir la spécification, les descriptions de test, les user stories et les descriptions de fonctionnalités sont la spécification, dans le sens des «arbres morts».

En résumé, le processus TDD en bref est:

  • définir un projet en termes de fonctionnalités
  • décrire les parties prenantes, le comportement et l'objectif de chaque fonctionnalité à l'aide de user stories
  • spécifier les données attendues, les événements / conditions de déclenchement et les comportements / résultats associés à une user story à l'aide de descriptions de test [et ceci complète la «spécification»]
  • choisissez un ensemble de fonctionnalités pour chaque itération; les itérations doivent être courtes [j'omets les étapes de planification et d'estimation par souci de concision]
    • coder un test pour une fonctionnalité (il échouera, mais vous deviez prendre des décisions d'API pour coder le test)
    • implémenter suffisamment la fonctionnalité pour que le test réussisse
    • refactoriser le code si nécessaire
    • répéter avec le prochain test jusqu'à ce que la fonctionnalité soit terminée
    • répéter avec la fonction suivante jusqu'à la fin de l'itération
  • répéter avec l'itération suivante jusqu'à la fin du projet

la quantité de conception, d'architecture, de documentation de support, etc. que vous choisissez de faire ne fait pas partie de TDD. Il existe certaines «meilleures pratiques» pratiques sur lesquelles vous pouvez lire, mais gardez à l'esprit que ce sont les «meilleures» pratiques dans l'atelier de quelqu'un d'autre , pas la vôtre.

notez que le point est pour le client et le développeur de proposer les fonctionnalités et d'écrire les histoires et les descriptions de test ensemble , pour une compréhension mutuelle

donc, avec cela à l'écart, la question initiale était:

quel est le rôle d'un architecte logiciel dans TDD?

Et la réponse courte est:

La même chose que jamais, la même chose que jamais. - David Byrne

EDIT: La réponse longue est: l'architecte joue les rôles habituels de visionnaire / investigateur / irritant / support / backstop pendant tout le processus, si nécessaire.

EDIT 2: désolé d'avoir raté le point des sous-questions! Chacun est responsable de la rédaction des spécifications; tous les développeurs, y compris l'architecte, le cas échéant, plus le client . Les développeurs codent également les tests.

Steven A. Lowe
la source
1
Cela a du sens, mais les seules étapes dont j'ai jamais entendu parler dans le contexte du TDD sont les cinq étapes de vos cinq balles internes (décrivant le processus de refonte rouge-vert). Les puces restantes font-elles vraiment partie du TDD ou font-elles partie d'une méthodologie plus large comme Agile ou DDD?
Robert Harvey
@Robert hmmm ... bonne question! techniquement, les autres balles seraient XP; J'ai appris XP et TDD en même temps et je n'ai jamais pensé à les séparer. Jusqu'à maintenant ;-)
Steven A. Lowe
@Robert a fait une lecture de rappel; voir les modifications (FYI utilisant XP ref extremeprogramming.org et TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )
Steven A. Lowe
Hmm, le lien que vous avez fourni pour TDD indique que TDD est vraiment une conception pilotée par les tests . Maintenant je suis de retour où j'ai commencé. "Vous concevez de manière organique, avec le code en cours d'exécution fournissant un retour entre les décisions."
Robert Harvey
1
@Robert les modifications m'ont certainement aidé à mieux comprendre la question. Je prends le D comme développement et l'interprète comme l'ensemble du cycle de vie, pas seulement la partie codage. TDDev est un bon moyen d'acquérir des compétences architecturales - le refactoring a tendance à en pousser un dans cette direction
Steven A. Lowe
1

L'architecte logiciel n'écrit pas tous les tests. Ce serait mettre trop sur les épaules d'une personne à mon avis.

L'architecte logiciel doit être capable de dessiner un formulaire initial pour l'API que les développeurs écrivent ensuite des tests pour cela et puis construire l'API. Cependant, l'architecte logiciel peut avoir diverses normes de code qui ne sont pas nécessairement testables, par exemple la documentation ou les conventions de dénomination. Il est également possible que l'API initiale manque certains appels. Au fur et à mesure de la mise en œuvre, de nouveaux appels sont ajoutés à l'API. Ainsi, l'API connaîtra une croissance organique à mesure que la base de code se développera, mais le rôle de l'architecte est de fournir des directives de haut niveau et de s'assurer qu'elles sont suivies.

Il peut certainement y avoir des cas où une équipe peut décider de ne pas avoir d'architecte logiciel, mais en fonction de l'échelle de l'API et de la société impliquée, cela peut ou non être une bonne idée.

JB King
la source