Je suis très nouveau à TDD, pas encore commencé à l'utiliser. Mais je sais que nous devons écrire un test d'abord, puis le code réel pour réussir le test et le refacteur jusqu'à la bonne conception.
Mon inquiétude sur TDD est que l'endroit où il convient à notre SDLC. Supposons que je reçoive une obligation de faire du système de traitement des commandes. Maintenant, sans aucun modèle et conception de ce système, comment puis-je commencer à écrire des tests? N'avons-nous pas besoin de définir les entités et ses attributs à procéder? Sinon, est-il possible de développer un grand système sans aucun design?
9 Réponses :
Bien sûr, vous avez besoin d'une analyse fonctionnelle solide, y compris un modèle de domaine, sans savoir ce que vous devrez créer en premier lieu, il est impossible d'écrire vos tests d'unité.
Seulement vous ne pouvez pas d'abord faire une "analyse fonctionnelle solide", car vous auriez besoin de savoir ce que vous aurez finalement besoin de cela, c'est-à-dire prédire l'avenir -> ne fonctionne pas. Si quelqu'un demande une "analyse fonctionnelle solide", ils sont "aussi bons que nous savons en ce moment", puis ils se demandent pourquoi la conception a tous ces défauts pesky.
TDD implique qu'il existe une conception existante (interface externe) pour commencer. Vous devez avoir une sorte de conception à l'esprit afin de commencer à écrire un test. Certaines personnes diront que TDD lui-même nécessite une conception moins détaillée, car la loi de rédaction des tests fournit des commentaires au processus de conception, mais ces concepts sont généralement orthogonaux.
Ecrire un test d'abord vous oblige à penser à penser d'abord sur le domaine "fort>" Problème "/ fort> et agit comme une sorte de spécification. Ensuite, dans une 2ème étape, vous vous déplacez vers Solution Domain et implémentez la fonctionnalité.
TDD fonctionne bien itérativement:
Bien sûr, vous devez avoir une vision architecturale vague à l'arrivée (technologies, couches, exigences non fonctionnelles, etc.). Mais les fonctionnalités qui apportent une valeur ajoutée à votre application peuvent être introduites bien avec TDD.
Voir la question connexe TDD: Bon pour un démarreur?
avec TDD, vous ne vous souciez pas beaucoup de la conception. L'idée est que vous devez d'abord apprendre ce dont vous avez besoin avant de pouvoir commencer par un design utile. Les tests veillent à modifier facilement et de manière fiable votre application lorsque vous devez décider de votre conception.
Sans TDD, cela se produit: vous faites une conception (qui est probablement trop complexe dans certaines zones plus que vous avez oublié de prendre des faits importants en compte depuis que vous n'avez pas connu à leur sujet). Ensuite, vous commencez à mettre en œuvre la conception. Avec le temps, vous réalisez toutes les lacunes de votre conception, de sorte que vous le changez. Mais la modification de la conception ne change pas votre programme. Vous essayez maintenant de changer votre code pour vous adapter à la nouvelle conception. Étant donné que le code n'a pas été écrit pour être modifié facilement, cela finira par échouer, vous laissant avec deux designs (un cassé et l'autre dans un état inconnu) et le code qui ne correspond pas non plus.
Pour commencer avec TDD, tournez vos besoins en test. Pour ce faire, demandez "Comment savoir que cette exigence est remplie?" Lorsque vous pouvez répondre à cette question, écrivez un test qui implémente la réponse à cette question. Cela vous donne l'API que votre code (à écrire) doit adhérer à. C'est un design très simple, mais celui a) fonctionne toujours et b) qui est flexible (car vous ne pouvez pas tester le code encore moins de contrôle).
En commençant également par le test vous transformera à votre propre client. Depuis que vous essayez de faire le test aussi simple que possible, vous créerez une API simple qui rend le test de test.
Et au fil du temps, vous en apprendrez assez sur votre domaine de problème pour pouvoir faire une vraie conception. Depuis que vous avez de nombreux tests, vous pouvez ensuite modifier votre code pour adapter la conception. Sans ne rien briser de manière terminale sur le chemin.
C'est la théorie :-) En pratique, vous rencontrerez quelques problèmes, mais cela fonctionne plutôt bien. Ou plutôt, cela fonctionne mieux que toute autre chose que j'ai rencontrée jusqu'à présent.
Mais en donnant des exigences, le client demande toujours l'estimation de la mise en œuvre. Est-il possible d'estimer sans conception. Comme nous le savons, l'écriture de test et le code réel est une tâche parallèle, lorsque n Comment pouvons-nous faire l'estimation.
Vous commencez par parler des tests: le client doit vous aider à les éloigner (ce qui doit être testé, quels sont les résultats attendus, etc.). Cela vous donnera une bonne idée du nombre de tests dont vous avez besoin par fonctionnalité et de la manière dont la fonctionnalité "gros" ou complexe est.
Il devrait être appelé Conception pilotée par test , car c'est ce que c'est.
Il n'y a pas de raison pratique de séparer la conception en phase spécifique du projet. La conception arrive tout le temps. De la discussion initiale avec l'intervenant, grâce à la création, à l'estimation, à la création d'objets d'utilisateur, puis au cours de vos sessions TDD.
Si vous voulez formaliser la conception en utilisant UML ou autre, c'est bon, gardez à l'esprit que le code est la conception et tout le reste est juste une approximation. Et rappelez-vous que Yagni s'applique à tout, y compris les documents de conception.
Vous avez besoin d'une forme de spécification plutôt que d'une forme de conception - la conception est à peu près La forme la plus courante de spécifications que j'ai vue utilisée avec TDD (et d'autres processus agiles) sont - un type informel de "cas d'utilisation" qui a tendance à être exprimé dans des phrases anglophones quelque peu stéréotypées telles que "en tant que, je peux" (la forme des histoires d'utilisateurs est plus ou moins rigide en fonction du style / processus exact en cours d'utilisation).
Par exemple, "en tant que client, je peux commencer une nouvelle commande", "en tant que client, je peux ajouter une entrée à une commande existante", etc., peut-être être typique si c'est ce que votre "commande L'entrée "est à propos (les histoires d'utilisateurs seraient assez différentes si le système n'était pas" Self-Service "pour les utilisateurs mais plutôt destiné à être utilisé par les représentants des ventes entrant des ordres au nom des utilisateurs, bien sûr - sans savoir quel genre du système d'entrée de commande est signifié, il est impossible de procéder de manière judicieuse, c'est pourquoi je dis que vous avez besoin de spécification sur ce que le système va faire, bien que typiquement pas encore une idée complète de < em> comment ça va le faire).
Il y a deux niveaux de développement piloté par TDD, ATDD ou Acceptation, et TDD normal qui est entraîné par des tests unitaires.
Je suppose que la relation entre TDD et la conception est influencée par le concept quelque peu "agile" que le code source est la conception d'un produit logiciel. Beaucoup de gens renforcent cela en traduisant TDD en tant que conception pilotée par test plutôt que de développement. Cela donne beaucoup de sens que TDD devrait être considéré comme ayant beaucoup plus à voir avec la conduite de la conception que de tester. Avoir l'acceptation et les tests unitaires à la fin de celle-ci est un bel effet secondaire.
Je ne peux pas vraiment dire trop de là où il s'inscrit dans votre SDLC sans en savoir plus à ce sujet, mais un bon flux de travail est:
pour chaque histoire d'utilisateur:
Ecrire des tests d'acceptation à l'aide d'un outil tel que fitnesse ou concombre , cela spécifierait les sorties souhaitées pour les entrées données, d'une perspective que l'utilisateur comprend. Ce niveau automatise les spécifications ou peut même remplacer la documentation des spécifications dans des situations idéales.
Maintenant, vous aurez probablement une vague idée du type de conception de logiciels dont vous pourriez avoir besoin aussi loin que les classes / comportements, etc.
pour chaque comportement:
Écrivez un test d'échec qui montre comment le code d'appel que vous souhaitez utiliser la classe .
implémenter le comportement qui rend le test de test
refacteur à la fois le test et le code réel pour refléter une bonne conception.
aller sur le prochain comportement.
Allez sur la prochaine histoire d'utilisateur.
Bien sûr, tout le temps vous envisagerez de l'évolution de la conception de haut niveau du système. Idéalement, TDD mènera à une conception flexible aux niveaux inférieurs permettant à la conception élevée appropriée d'évoluer au fur et à mesure que vous allez plutôt que d'essayer de le deviner au début.
@Kurt la meilleure réponse à propos de TDD que j'ai jamais vu. Toutes nos félicitations. (+1)
Alors, qu'en est-il de tous les modèles et principes de conception. Lors de l'écriture de test et du code réel parallèle, comment pouvons-nous identifier où appliquer le principe de modèle et de conception.
Et d'où vit notre produit logiciel, si chaque développeur se développe sur leur style. La plupart du temps, une partie est développée par une équipe et autre par une autre équipe. Il invitera un problème de compatibilité entre les composants.
@Nirajan identifiant les modèles et les principes de conception provient de l'apprentissage et de l'expérience. TDD aide réellement à éviter naturellement beaucoup de modèles anti-motifs. C'est un sujet assez détaillé, mais des livres de Robert C. Martin parmi d'autres sont de grandes sources de connaissances sur ce sujet. Travailler ensemble à travers les équipes séparées est également un gros sujet. Trop gros pour traiter dans ce commentaire, mais travailler dans des tranches verticales de fonctionnalité, plutôt que des couches aide. La communication est essentielle pour éviter les problèmes et les tests que vous avez à titre d'effet secondaire de l'aide de TDD les identifier plus rapidement.
Merci pour votre grande suggestion. En fait, j'écris quelques tests pour la demande de démonstration. Comment décider de quelle mesure nous devons refroidir le code. Comme je suis nouveau à TDD, est-ce une bonne pratique d'utiliser la même chose dans mon projet, sans avoir suffisamment de connaissances sur elle.
J'utilise un développement axé sur le test au programme et je peux dire de l'expérience qu'il aide à créer un code plus robuste, ciblé et plus simple. Ma recette pour TDD va quelque chose aime ceci:
Vous avez terminé à ce stade. Vous avez écrit le code minimum dont vous avez besoin pour implémenter votre fonctionnalité et vous savez qu'il est robuste à cause de vos tests. Vous pourrez également détecter si vous cassez des choses à l'avenir. Si vous trouvez des bugs, ajoutez un test d'unité à tester pour ce bogue (vous n'avez peut-être pas pensé d'un boîtier de bord par exemple). Et vous savez que si vous ajoutez plus de fonctionnalités à votre code, vous ne le rendrez pas incompatible avec le code existant qui utilise votre fonctionnalité.
J'aime cette méthode. Me fait sentir chaud et flou à l'intérieur.
Permettez-moi de partager ma vue:
Si vous souhaitez créer une application, vous devez le tester, par exemple, vérifiez les valeurs des variables que vous créez par l'inspection du code, de supprimer rapidement un bouton que vous pouvez cliquer sur et exécutera une partie du code et de la pop. Une boîte de dialogue pour afficher le résultat de l'opération, etc. D'autre part, TDD change votre état d'esprit.
Communément, vous comptez simplement sur l'environnement de développement, comme Visual Studio pour détecter des erreurs lorsque vous codez et compilez et dans votre tête, vous connaissez l'exigence et simplement le codage et les tests via des boutons et des fenêtres contextuelles ou de code. Ceci est un développement dirigé par le débogage de la syntaxe. Mais lorsque vous faites TDD, est un "développement axé sur le débogage sémantique", car vous écrivez d'abord vos pensées / buts de votre application en utilisant des tests (qui et une version plus dynamique et répétable d'une carte blanche) qui teste la logique (ou "Sémantican") de votre application et échoue chaque fois que vous avez une erreur sémantique, même si votre application passe une erreur de syntaxe (sur la compilation).
En pratique, vous ne savez peut-être pas que toutes les informations requises pour construire l'application, car TDD vous oblige à écrire d'abord des tests, vous êtes obligé de poser plus de questions sur le fonctionnement de l'application à un stade très précoce de développement plutôt que de construire beaucoup seulement pour découvrir que beaucoup de ce que vous avez écrit n'est pas nécessaire (ni à ne le permettent pas pour le moment). Vous pouvez vraiment éviter de perdre votre temps précieux avec TDD (même si cela peut ne pas se sentir comme ça initialement)
Voir la réponse de l'oncle Bob à une question connexe ici- Stackoverflow.com/Questtions/1983330/...