Inconvénients du développement piloté par les tests? [fermé]

https://stackoverflow.com/questions/64333

09-06-2019
|

Question

Qu'est-ce que je perds en adoptant une conception pilotée par des tests?

N'indiquez que les négatifs; ne pas énumérer les avantages écrits sous une forme négative.

La solution

Plusieurs inconvénients (et je ne prétends pas qu’il n’ya aucun avantage - en particulier lors de l’écriture de la fondation d’un projet - cela gagnerait beaucoup de temps à la fin):

Un investissement de temps considérable. Dans les cas simples, vous perdez environ 20% de la mise en œuvre réelle, mais dans les cas complexes, vous en perdez beaucoup plus.
Complexité supplémentaire. Pour les cas complexes, vos scénarios de test sont plus difficiles à calculer. Dans de tels cas, nous vous recommandons d'essayer d'utiliser un code de référence automatique qui s'exécutera en parallèle dans la version / le test de débogage. lancer, au lieu du test unitaire des cas les plus simples.
Impact sur la conception. Parfois, la conception n'est pas claire au début et évolue au fil du temps. Cela vous obligera à refaire votre test, ce qui vous fera perdre beaucoup de temps. Je suggérerais de reporter les tests unitaires dans ce cas jusqu'à ce que vous ayez une idée de la conception.
Modification continue. Pour les structures de données et les algorithmes de boîte noire, les tests unitaires seraient parfaits, mais pour les algorithmes qui ont tendance à être modifiés, peaufinés ou ajustés, cela peut entraîner un investissement de temps considérable. revendication n'est pas justifiée. Donc, utilisez-le quand vous pensez que cela correspond au système et ne forcez pas la conception à s’adapter au TDD.

Autres conseils

Si vous voulez faire "réel" TDD (lisez: testez d’abord avec les étapes rouge, vert et refactor), puis commencez également à utiliser des mocks / stubs lorsque vous souhaitez tester des points d’intégration.

Lorsque vous commencerez à utiliser des simulacres, après un certain temps, vous voudrez commencer à utiliser l’Injection de dépendance (DI) et un conteneur Inversion of Control (IoC). Pour ce faire, vous devez utiliser des interfaces pour tout (ce qui présente de nombreux pièges).

À la fin de la journée, vous devez écrire beaucoup plus de code que si vous le faites simplement "à l'ancienne". Au lieu d’une simple classe client, vous devez également écrire une interface, une classe fictive, une configuration IoC et quelques tests.

Et rappelez-vous que le code de test doit également être conservé et entretenu. Les tests doivent être aussi lisibles que tout le reste et il faut du temps pour écrire du bon code.

De nombreux développeurs ne comprennent pas très bien comment faire tout cela "de la bonne façon". Mais comme tout le monde leur dit que TDD est le seul véritable moyen de développer des logiciels, ils essaient simplement du mieux qu'ils peuvent.

C'est beaucoup plus difficile qu'on pourrait le penser. 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, le mauvais sens. Et personne ne convient à quoi devrait ressembler un bon test, pas même les soi-disant gourous.

Tous ces tests rendent beaucoup plus difficile le "changement". (à l'opposé de la refactorisation), le comportement de votre système et les simples modifications deviennent trop difficiles et prennent trop de temps.

Si vous lisez la littérature TDD, il y a toujours de très bons exemples, mais souvent dans les applications réelles, vous devez disposer d'une interface utilisateur et d'une base de données. C'est là que le TDD devient très difficile et que la plupart des sources n'offrent pas de bonnes réponses. Et s’ils le font, cela implique toujours plus d’abstractions: objets fictifs, programmation pour une interface, modèles MVC / MVP, etc., qui exigent à 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 quelques notions de bonne architecture, vous devez vraiment y penser à deux fois la route TDD.

Lorsque vous atteignez le point où vous avez un grand nombre de tests, la modification du système peut nécessiter la réécriture de certains ou de la totalité de vos tests, en fonction de ceux qui ont été invalidés par les modifications. Cela pourrait transformer une modification relativement rapide en une opération qui prend beaucoup de temps.

De plus, vous pouvez commencer à prendre des décisions de conception basées davantage sur le TDD que sur de bons principes de conception. Alors que vous aviez peut-être une solution très simple et facile, impossible à tester comme le demande TDD, vous disposez maintenant d’un système beaucoup plus complexe qui est en réalité plus sujet aux erreurs.

Je pense que le plus gros problème pour moi est l'énorme perte de temps qu'il faut "pour y arriver". Je suis toujours au tout début de mon parcours avec TDD (voir mon blog pour les mises à jour de mes aventures de test si vous êtes intéressé) et j’ai littéralement passé heures à démarrer.

Il faut beaucoup de temps pour que votre cerveau passe en "mode test". et en écrivant " code testable " est une compétence en soi.

TBH, je ne suis pas du tout en désaccord avec les commentaires de Jason Cohen Dans ma nouvelle méthode de travail, je n'ai pas utilisé plus de méthodes publiques qu'auparavant . Toutefois, cela implique des modifications architecturales et vous permet de "brancher à chaud". modules de code pour rendre tout le reste plus facile à tester. Ne pas rendre les éléments internes de votre code plus accessibles à cette fin. Sinon, nous sommes de retour à la case départ avec tout ce qui est public, où est l’encapsulation dans cela?

Donc, (OMI) en un mot:

Le temps nécessaire pour réfléchir (c'est-à-dire réellement tester ).
Les nouvelles connaissances requises pour savoir comment écrire du code testable.
Comprendre les modifications architecturales requises pour rendre le code testable.
Augmentez vos compétences en matière de " TDD-Coder " en essayant d’améliorer toutes les autres compétences requises pour notre glorieux métier de programmation:)
Organisez votre base de code pour inclure le code de test sans visser votre code de production.

PS: Si vous souhaitez créer des liens vers des éléments positifs, j’ai posé et répondu à plusieurs questions à ce sujet, consultez mon profil .

Depuis quelques années que je pratique le développement piloté par les tests, je dois dire que les plus gros inconvénients sont les suivants:

Vente à la direction

TDD se fait mieux par paires. En premier lieu, il est difficile de résister à l'envie d'écrire simplement la mise en œuvre lorsque vous SAVONS d'écrire une instruction if / else . Mais une paire vous gardera sur la tâche parce que vous le gardez sur la tâche. Malheureusement, de nombreuses entreprises / dirigeants ne pensent pas que cela représente une utilisation judicieuse des ressources. Pourquoi payer pour que deux personnes écrivent une fonctionnalité alors que deux fonctionnalités doivent être réalisées en même temps?

Le vendre à d'autres développeurs

Certaines personnes n’ont simplement pas la patience nécessaire pour écrire des tests unitaires. Certains sont très fiers de leur travail. Ou alors, certaines personnes aiment simplement voir des méthodes / fonctions compliquées se détacher de la fin de l'écran. Le TDD ne convient pas à tout le monde, mais j'aimerais vraiment qu'il en soit ainsi. Cela faciliterait tellement le travail de maintenance pour ces pauvres âmes qui héritent du code.

Conserver le code de test avec votre code de production

Idéalement, vos tests ne fonctionneront que lorsque vous prendrez une mauvaise décision concernant le code. C'est-à-dire que vous pensiez que le système fonctionnait dans un sens et qu'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 exactement comment votre nouveau code affectera le système. Toutefois, si vos tests sont mal écrits, étroitement couplés ou, pire encore, générés (test VS contre la toux ), le maintien de vos tests peut devenir rapidement une chorale. Et, après que suffisamment de tests commencent à causer plus de travail que la valeur perçue qu'ils créent, alors les tests seront la première chose à supprimer lorsque les plannings seront compressés (par exemple, le temps presse)

Rédaction des tests de manière à tout couvrir (couverture de code à 100%)

Idéalement, si vous respectez la méthodologie, votre code sera testé à 100% par défaut. En règle générale, je pense avoir une couverture de code supérieure à 90%. Cela se produit généralement lorsque j'ai une architecture de style de modèle et que la base est testée. J'essaie de couper les angles et de ne pas tester les personnalisations du modèle. De plus, j'ai constaté que lorsque je rencontre un nouvel obstacle que je n'avais pas encore rencontré, je dois apprendre à le tester. Je vais admettre que certaines lignes de code ont été écrites à l'ancienne, mais j'aime beaucoup avoir ce code à 100%. (Je suppose que je réussissais trop bien à l’école, euh skool).

Cependant, avec cela, je dirais que les avantages du TDD dépassent de loin les inconvénients de la simple idée que si vous pouvez réaliser une bonne série de tests qui couvrent votre application mais ne sont pas si fragiles qu’un changement les casse tous. , vous pourrez continuer à ajouter de nouvelles fonctionnalités au 300e jour de votre projet comme au jour 1. Cela n’arrive pas à tous ceux qui essaient de TDD pensant que c’est une solution miracle à tout leur code infesté de bogues, et ils pense que ça ne peut pas marcher, tout simplement.

Personnellement, j’ai constaté que, avec TDD, j’écris du code plus simple, je passe moins de temps à débattre du point de savoir si une solution de code particulière fonctionnera ou non, et que je ne crains pas de modifier les lignes de code qui ne répondent pas aux critères. défini par l'équipe.

Le TDD est une discipline difficile à maîtriser. Je le pratique depuis quelques années et j'apprends toujours de nouvelles techniques de test tout le temps. C'est un énorme investissement de temps au départ, mais à long terme, votre durabilité sera beaucoup plus grande que si vous n'aviez pas de tests unitaires automatisés. Maintenant, si seulement mes patrons pouvaient comprendre cela.

Sur votre premier projet TDD, il y a deux pertes importantes, le temps et la liberté personnelle

Vous perdez du temps parce que:

La création d’une suite complète de tests unitaires et de tests de maintenance, refactorables et maintenables, ajoute un temps considérable à la première itération du projet. C'est peut-être un gain de temps à long terme, mais vous pouvez également avoir le temps de ne pas perdre votre temps.
Vous devez choisir et devenir un expert dans un ensemble d'outils de base. Un outil de test unitaire doit être complété par une sorte de framework moqueur et les deux doivent faire partie de votre système de construction automatisé. Vous souhaitez également sélectionner et générer les mesures appropriées.

Vous perdez votre liberté personnelle parce que:

TDD est une manière très disciplinée d’écrire un code qui a tendance à se frotter contre ceux qui se trouvent en haut et en bas de l’échelle des compétences. Toujours écrire le code de production d'une certaine manière et soumettre votre travail à une évaluation continue par des pairs peut effrayer vos meilleurs et vos plus mauvais développeurs et même entraîner une perte d'effectifs.
La plupart des méthodes agiles qui intègrent TDD exigent que vous parliez continuellement au client de ce que vous proposez d'accomplir (dans cette histoire / journée / quoi que ce soit d'autre) et quels sont les avantages. Une fois de plus, ce n’est pas la tasse de thé de tout le monde, du côté des développeurs comme des clients.

J'espère que cela vous aidera

TDD vous demande de planifier le fonctionnement de vos classes avant d'écrire du code pour réussir ces tests. C’est à la fois un avantage et un inconvénient.

Je trouve difficile d’écrire des tests dans un "vide". --avant qu'un code ait été écrit. Dans mon expérience, j'ai tendance à trébucher sur mes tests chaque fois que je pense inévitablement à quelque chose en écrivant mes cours que j'ai oublié en écrivant mes tests initiaux. Ensuite, il est temps non seulement de refactoriser mes cours, mais également de passer mes tests. Répétez cette opération trois ou quatre fois et cela peut devenir frustrant.

Je préfère rédiger d’abord un brouillon de mes cours, puis d’écrire (et de maintenir) une batterie de tests unitaires. Une fois que j'ai un brouillon, TDD fonctionne bien pour moi. Par exemple, si un bogue est signalé, je vais écrire un test pour exploiter ce bogue, puis corriger le code pour que le test réussisse.

Avec le TDD, le prototypage peut être très difficile - lorsque vous ne savez pas quel chemin vous allez emprunter pour trouver une solution, il peut être difficile d’écrire les tests au préalable (en dehors des tests très généraux). Cela peut être une douleur.

Honnêtement, je ne pense pas que ce soit pour le "développement de base" " pour la grande majorité des projets, cependant, il y a un réel inconvénient; les gens qui croient que leur code est assez bon pour ne pas avoir besoin d’essais (ce n’est jamais le cas) et les gens qui ne veulent tout simplement pas avoir la peine de prendre la peine de les écrire en parlent beaucoup plus que ce qu’ils devraient être.

Eh bien, et cet étirement, vous devez déboguer vos tests. En outre, il faut un certain temps pour écrire les tests, bien que la plupart des gens s'accordent pour dire qu'il s'agit d'un investissement initial rentable tout au long de la vie de l'application, à la fois pour le débogage rapide et pour la stabilité.

Le problème le plus important que j’ai eu personnellement avec lui, cependant, est d’avoir la discipline pour écrire les tests. Dans une équipe, en particulier une équipe établie, il peut être difficile de les convaincre que le temps passé en vaut la peine.

Si vos tests ne sont pas très approfondis, vous risquez de tomber dans un faux sentiment de "tout fonctionne". juste parce que vous passez des tests. Théoriquement, si vos tests réussissent, le code fonctionne. mais si nous pouvions écrire du code parfaitement la première fois, nous n'aurions pas besoin de tests. La morale ici est de vous assurer de faire un test de cohérence avant de déclarer quelque chose de complet, ne vous fiez pas seulement aux tests.

Sur cette note, si votre contrôle d'intégrité trouve quelque chose qui n'a pas été testé, veillez à revenir en arrière et à écrire un test à cet effet.

L’inconvénient de TDD est qu’elle est généralement étroitement associée à la méthodologie "agile", qui n'accorde aucune importance à la documentation d'un système, mais plutôt à la raison pour laquelle un test "devrait" restituer un résultat spécifique. la valeur plutôt que toute autre réside uniquement dans la tête du développeur.

Dès que le développeur quitte ou oublie la raison pour laquelle le test renvoie une valeur spécifique et non une autre, vous êtes foutu. TDD est acceptable SI il est correctement documenté et entouré d’une documentation lisible par l’homme (par exemple, un gestionnaire aux cheveux pointus) à laquelle on pourra se référer dans 5 ans lorsque le monde changera et que votre application doit également le faire.

Lorsque je parle de documentation, ce n’est pas un texte de présentation en code, c’est une écriture officielle qui existe à l’extérieur de l’application, telle que des cas d’utilisation et des informations générales pouvant être consultées par les gestionnaires, les avocats et le pauvre SAP. doit mettre à jour votre code en 2011.

J'ai rencontré plusieurs situations dans lesquelles TDD me rend fou. Pour en nommer:

Maintenabilité du scénario de test:

Si vous êtes dans une grande entreprise, il y a de fortes chances que vous n'ayez pas à écrire les cas de test ou du moins que la plupart d'entre eux soient écrits par quelqu'un d'autre lorsque vous entrez dans l'entreprise. Les fonctionnalités d'une application changent de temps en temps et si vous n'avez pas de système en place, tel que HP Quality Center, pour le suivre, vous deviendrez fou en un rien de temps.

Cela signifie également qu'il faudra beaucoup de temps aux nouveaux membres de l'équipe pour comprendre ce qui se passe dans les scénarios de test. Cela peut à son tour se traduire par davantage d’argent.
Tester la complexité de l'automatisation:

Si vous automatisez une partie ou la totalité des scénarios de test dans des scripts de test exécutables par une machine, vous devez vous assurer que ces scripts de test sont synchronisés avec les scénarios de test manuels correspondants et en conformité avec les modifications apportées à l'application.

De plus, vous passerez du temps à déboguer les codes qui vous aident à détecter les bogues. À mon avis, la plupart de ces bugs proviennent de l'incapacité de l'équipe de test à refléter les modifications apportées à l'application dans le script de test d'automatisation. Les modifications apportées à la logique commerciale, à l'interface graphique et à d'autres éléments internes peuvent empêcher vos scripts de s'exécuter ou de s'exécuter de manière non fiable. Parfois, les changements sont très subtils et difficiles à détecter. Une fois que tous mes scripts ont signalé un échec car ils avaient basé leur calcul sur les informations du tableau 1, tandis que le tableau 1 était désormais le tableau 2 (car une personne avait échangé le nom des objets du tableau dans le code de l'application).

Le plus gros problème concerne les personnes qui ne savent pas écrire les tests unitaires appropriés. Ils écrivent des tests qui dépendent les uns des autres (et ils fonctionnent très bien avec Ant, mais échouent soudainement lorsque je les exécute à partir d’Eclipse, simplement parce qu’ils sont exécutés dans un ordre différent). Ils écrivent des tests qui ne testent rien en particulier: ils déboguent le code, vérifient le résultat et le modifient en test, en l'appelant "test1". Ils élargissent le champ des classes et des méthodes, simplement parce qu'il sera plus facile d'écrire des tests unitaires pour eux. Le code des tests unitaires est terrible, avec tous les problèmes de programmation classiques (couplage lourd, méthodes longues de 500 lignes, valeurs codées en dur, duplication de code) et est un enfer à maintenir. Pour des raisons étranges, les personnes considèrent les tests unitaires comme quelque chose de inférieur au test "réel". code, et ils ne se soucient pas de leur qualité du tout. : - (

Vous perdez beaucoup de temps à écrire des tests. Bien sûr, cela pourrait être sauvegardé à la fin du projet en attrapant les bugs plus rapidement.

Vous perdez la possibilité de dire que vous êtes "terminé". avant de tester tout votre code.

Vous perdez la capacité d'écrire des centaines ou des milliers de lignes de code avant de l'exécuter.

Vous perdez la possibilité d'apprendre par le débogage.

Vous perdez la possibilité d'envoyer du code dont vous n'êtes pas sûr.

Vous perdez la liberté de coupler étroitement vos modules.

Vous perdez l'option de ne pas écrire la documentation de conception de bas niveau.

Vous perdez la stabilité associée au code que tout le monde a peur de changer.

Vous perdez le titre de "hacker".

Le plus gros inconvénient est que si vous voulez vraiment faire correctement le TDD, vous devrez échouer beaucoup avant de réussir. Étant donné le nombre de sociétés de logiciels qui travaillent (dollar par KLOC), vous serez éventuellement viré. Même si votre code est plus rapide, plus propre, plus facile à gérer et comporte moins de bogues.

Si vous travaillez dans une entreprise qui vous paie en fonction des KLOC (ou des exigences mises en œuvre - même si elles n’ont pas été testées), restez à l’écart de la TDD (ou des révisions de code, ou de la programmation par paires, de l’intégration continue, etc., etc.). ).

J'appuie la réponse sur le temps de développement initial. Vous perdez également la capacité de travailler confortablement sans la sécurité des tests. J'ai aussi été décrit comme un dingue de TDD, de sorte que vous pourriez perdre quelques amis;)

Se concentrer sur des exigences difficiles et imprévues est le fléau constant du programmeur. Le développement piloté par les tests vous oblige à vous concentrer sur les exigences mondaines déjà connues et limite votre développement à ce qui a déjà été imaginé.

Pensez-y, vous finirez probablement par concevoir des scénarios de test spécifiques. Par conséquent, vous ne serez pas créatif et ne commencerez pas à penser "ce serait bien si l'utilisateur pouvait exécuter X, Y et Z". Par conséquent, lorsque cet utilisateur commence à s'enthousiasmer pour les exigences X, Y et Z potentielles, il est possible que votre conception soit trop rigide sur des scénarios de test déjà spécifiés et qu'il sera difficile de l'ajuster.

Ceci, bien sûr, est une épée à double tranchant. Si vous passez tout votre temps à concevoir pour chaque utilisateur imaginable, imaginable, X, Y et Z qu'un utilisateur puisse désirer, vous ne pourrez jamais rien terminer. Si vous complétez quelque chose, il sera impossible à quiconque (y compris vous-même) d’avoir une idée de ce que vous faites dans votre code / design.

Il est perçu comme plus lent. Ce n'est pas vrai à long terme, mais vous finirez par écrire plus de code, vous perdrez du temps à "tester sans coder". C’est un argument imparfait, mais vous l’avez demandé!

Il peut être difficile et long de passer des tests d’écriture pour "aléatoire". des données telles que les flux XML et les bases de données (pas si difficile). Dernièrement, j'ai travaillé avec des flux de données météorologiques. C'est assez déroutant d'écrire des tests pour ça, du moins, vu que je n'ai pas beaucoup d'expérience avec le TDD.

Vous allez perdre de grandes classes avec de multiples responsabilités. Vous allez aussi probablement perdre de grandes méthodes avec de multiples responsabilités. Vous pouvez perdre une partie de votre capacité de refactorisation, mais vous perdez également une partie de votre besoin de refactoriser.

Jason Cohen a dit quelque chose comme: TDD nécessite une certaine organisation pour votre code. Cela pourrait être incorrect sur le plan architectural; Par exemple, comme les méthodes privées ne peuvent pas être appelées en dehors d’une classe, vous devez les rendre non testables pour les rendre testables.

Je dis que cela indique une abstraction manquée - si le code privé doit vraiment être testé, il devrait probablement être dans une classe séparée.

Dave Mann

Vous devez écrire des applications de manière différente: une application permettant de les tester. Vous seriez surpris de voir à quel point c'est difficile au début.

Certaines personnes trouvent trop difficile de penser à ce qu’elles vont écrire avant de l’écrire. Des concepts tels que se moquer peuvent être difficiles pour certains aussi. TDD dans les applications existantes peut être très difficile si elles ne sont pas conçues pour les tests. TDD autour de frameworks qui ne sont pas conviviaux pour TDD peut également être un combat.

Le TDD étant une compétence, les développeurs débutants peuvent avoir des difficultés au début (principalement parce qu’ils n’ont pas appris à travailler de cette façon).

Dans l’ensemble, les inconvénients sont résolus à mesure que les personnes acquièrent des compétences et vous finissez par extraire le code "malodorant" et obtenir un système plus stable.

Il faut un certain temps pour y arriver et un peu pour commencer à le faire dans un projet mais ... je regrette toujours de ne pas avoir utilisé l'approche Test Driven lorsque je découvre des bugs stupides qu'un test automatisé aurait pu trouver très rapidement. De plus, TDD améliore la qualité du code.

les tests unitaires ont plus de code à écrire, donc un coût de développement initial plus élevé
c'est plus de code à maintenir
apprentissage supplémentaire requis

Bonne réponse à tous. J'ajouterais quelques moyens d'éviter le côté obscur du TDD:

J'ai écrit des applications pour faire leur propre test automatique randomisé. Le problème avec la rédaction de tests spécifiques est que même si vous en écrivez beaucoup, ils ne couvrent que les cas auxquels vous pensez. Les générateurs de tests aléatoires trouvent des problèmes auxquels vous n'avez pas pensé.
Le concept de nombreux tests unitaires implique que vous avez des composants qui peuvent entrer dans des états non valides, tels que des structures de données complexes. Si vous restez à l’écart des structures de données complexes, vous aurez beaucoup moins de choses à tester.
Dans la mesure où votre application le permet, évitez toute conception qui repose sur le bon ordre des notifications, des événements et des effets secondaires. Ceux-ci peuvent facilement être abandonnés ou brouillés, ils ont donc besoin de nombreux tests.

TDD nécessite une certaine organisation pour votre code. Cela peut être inefficace ou difficile à lire. Ou même architecturalement faux; Par exemple, comme les méthodes private ne peuvent pas être appelées en dehors d'une classe, vous devez rendre les méthodes non privées pour les rendre testables, ce qui est tout simplement faux.

Lorsque le code change, vous devez également modifier les tests. Avec le refactoring, cela peut être un beaucoup de travail supplémentaire.

Permettez-moi d'ajouter que si vous appliquez les principes BDD à un projet TDD, vous pouvez atténuer quelques-uns des inconvénients majeurs énumérés ici (confusion, incompréhensions, etc.). Si vous ne connaissez pas BDD, vous devriez lire l'introduction de Dan North. Il a proposé le concept en réponse à certains problèmes liés à l'application du TDD sur le lieu de travail. L’introduction de Dan sur BDD se trouve ici .

Je ne fais cette suggestion que parce que BDD s’attaque à certains de ces inconvénients et constitue un moyen de combler les lacunes. Vous devrez en tenir compte lors de la collecte de vos commentaires.

Vous devez vous assurer que vos tests sont toujours à jour, le moment où vous commencez à ignorer les feux rouges est le moment où les tests perdent leur sens.

Vous devez également vous assurer que les tests sont complets ou que, dès qu'un gros bogue apparaît, le type de gestion étouffant que vous avez finalement convaincu de vous laisser prendre du temps pour écrire plus de code se plaindra.

La personne qui a enseigné à mon équipe le développement agile ne croyait pas en la planification, vous n’avez écrit que pour la moindre exigence.

Sa devise était: refactor, refactor, refactor. J'ai fini par comprendre que le refactor voulait dire «ne pas planifier à l'avance».

Le temps de développement augmente: chaque méthode doit être testée. Si vous avez une grande application avec des dépendances, vous devez préparer et nettoyer vos données pour les tests.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow