Qui fait le développement piloté par les tests?

Je travaille dans l'espace entreprise depuis 4 ans et demi et j'ai remarqué qu'en règle générale, les entreprises ne sont pas des environnements propices au style de développement test-first. Les projets sont généralement à coût fixe, à échéance fixe et de style cascade. Tout test unitaire, s'il est effectué, intervient généralement après le développement dans la phase AQ et effectué par une autre équipe.

Avant de travailler pour une entreprise, j'ai consulté de nombreuses petites et moyennes entreprises, et aucune d'entre elles n'était disposée à payer pour un projet de développement de type test-first. Ils voulaient généralement que le développement commence immédiatement, ou après un court séjour de conception: c'est-à-dire quelque chose de plus proche d'Agile, bien que certains clients voulaient que tout soit conçu de manière similaire à la cascade.

Avec quels types de magasins, d'entreprises et de clients le développement piloté par les tests fonctionne-t-il le mieux? Quels types de projets tendent à favoriser le TDD?

Chaque ligne de code que j'écris utilise un développement piloté par les tests. Si la direction n'est pas prête à écrire des tests d'abord, je n'en parle pas à la direction. Je pense que le développement piloté par les tests est un meilleur processus.

Mon patron m'en a nourri un bon aujourd'hui, je pense que je vais le voler comme s'il le volait à quelqu'un d'autre.

"Vous attendriez-vous à ce qu'un menuisier mesure la planche avant de la couper?"

J'ai pris des cours de menuiserie au lycée et j'ai travaillé la construction à l'école. Notre mantra était toujours "mesurer deux fois, couper une fois", suivi du sarcastique "Je l'ai coupé et coupé encore et c'était encore trop court!"

Si vous testez après, vous créez un remaniement car le code que vous aurez écrit sera difficile à tester. Lorsque vous testez d'abord, ou même testez un peu au milieu mais avant de valider le logiciel que vous créez sera plus facile à tester. Une entreprise qui crée des tests unitaires après l'écriture du code de production pour satisfaire une liste de contrôle gaspille ses efforts.

L'intégration avec les logiciels existants difficiles à tester créera également des efforts supplémentaires, car vous devrez créer des coutures de test pour pouvoir contrôler les dépendances de votre nouveau code piloté par les tests. Dans certains cas, comme avec des frameworks qui font un usage intensif de l'état global et des objets divins, cela peut être très difficile à réaliser. La difficulté perçue du développement piloté par les tests est souvent due à une combinaison d'inexpérience avec la rédaction de bons tests et la tentative de tester du code étroitement couplé.

Vous pouvez tester le code de conduite même dans un projet en cascade, c'est une discipline d'ingénierie et non une technique de gestion de projet.

Je ne suis pas du tout fanatique du TDD, mais cela vous apprend beaucoup sur la conception de logiciels.

Gardez avec moi, car cela aura une saveur distincte .Net: p

En ce qui concerne les types de projets qui se prêtent à l'approche test-first, certaines choses que je devrais rechercher:

• avez-vous affaire à une base de code existante? Il est souvent extrêmement coûteux de moderniser une suite de tests. Ayez une idée du montant de la dette technique héritée
• certaines plates-formes et frameworks sont intrinsèquement hostiles aux tests. L'expérience récente qui est gravée dans mon esprit - SharePoint, par exemple, est très difficile (mais pas impossible) à TDD. Pour des choses comme celle-ci, vous devrez peut-être recourir à un produit d'isolateur commercial comme TypeMock peut vous aider.
• certaines approches de mise en œuvre se prêtent mieux à TDD que d'autres. Par exemple, ASP.Net avec code-behinds - pas si testable. ASP.Net MVC - testable. Silverlight avec code-behinds - pas si testable. Silverlight avec MVVM - testable.

En fin de compte, alors que "l'organisation" peut faire beaucoup pour soutenir le passage au test d'abord, le changement clé qui doit se produire est dans l'esprit des développeurs. J'ai abandonné l'approche «tu dois d'abord écrire tes tests» et je cherche plutôt des moments d'apprentissage.

+1 sur le commentaire de mpenrow à propos de ne pas dire à mgmt s'ils ont un problème avec cela: p

Votre situation ne changera pas rapidement, et la clé pour y arriver est de l'intégrer à votre discipline personnelle et d'être bon dans ce domaine, avant d'essayer de la pousser sur les autres. Si vous pouvez en être un exemple, vos managers devraient voir des avantages objectifs.

Vous pouvez également faire de bonnes analyses de rentabilisation:

• TDD peut être simplement résumé comme "spécification par rapport à laquelle le système peut automatiquement se vérifier". Ce n'est pas programmer différemment, ce n'est pas construire un produit différent.

• Les tests unitaires ne sont en réalité qu'une forme de tests automatisés; qui laisse simplement l'ordinateur faire pour lui-même ce que l'entreprise paiera probablement aux ingénieurs du secteur de la viande pour le faire manuellement. Les tests automatisés s'exécutent plus rapidement, de manière plus cohérente et, lorsqu'ils sont bien écrits, fournissent des commentaires et des descriptions et une direction rapides, concis et précis du problème.

• TDD, lorsqu'il est effectué par quelqu'un qui sait ce qu'il fait, produit des résultats aussi rapidement que le code en premier. Il y aura une courbe d'apprentissage / de formation (et, si vos ingénieurs sont issus de l'extrémité courte de la réserve de talents, cela peut entièrement tuer vos chances de pousser TDD - dans ce cas, le mieux que vous puissiez faire est de continuer à le défendre. et faire en sorte que la direction les remette en question plutôt que TDD)

• TDD consiste avant tout à réfléchir à la tâche à accomplir avant de la lancer. C'est dans le sens de "mesurer deux fois, couper une fois" - la mesure supplémentaire ajoute une quantité marginale de temps à la tâche, mais évite de jeter votre ressource la plus précieuse - les heures de développement).

... et n'oubliez pas; la chose la plus importante que vous puissiez faire est de donner l'exemple. Si vous êtes rude en TDD, investissez quelques heures supplémentaires pour devenir meilleur. Une fois que vous êtes compétent, commencez simplement à le faire au travail (vos gestionnaires se plaindraient-ils vraiment que vous passiez des tests?). Combattez une bataille à la fois et faites des pas vers celle-ci - aller pour tout le shebang entraînera probablement un échec et le blâme vous tombera si vous poussiez fort pour cela.

Je fais. C'est mon moyen de développement préféré et je travaille pour une grande société financière qui est heureuse de travailler comme je l'entends tant que je respecte les délais et que je produis un code de qualité. Fait correctement, le premier développement du test ne doit pas prendre plus de temps que le test après le développement et n'oublions pas les autres avantages du premier développement du test avec moins de défauts après les tests du système plus tard.

La clé pour faire TDD est de simplement le faire dans le cadre de l'écriture de votre code, et si nécessaire, vous ne dites à personne que vous le faites. Il n'est pas nécessaire d'expliquer tout ce que vous faites. Votre résultat final est un code fonctionnel.

Si vous expliquez «J'écris des tests», alors les pouvoirs en place peuvent dire «Oh, nous pouvons éliminer cela! Mais si vous ne le dites à personne, vous avez toujours les tests comme résidu du processus de codage.

La programmation est plus que de taper des instructions de travail dans un éditeur. Si les gens ne peuvent pas gérer cela, alors protégez-les de cette vérité jusqu'à ce qu'ils soient prêts à y faire face. «Prêt à le gérer» dans ce cas signifie que vous avez un ou deux projets terminés, réalisés à temps avec un code solide et fiable, et oh oui, regardez, vous avez aussi des tests unitaires.

C'est triste à dire, je n'ai pas eu la chance de l'utiliser moi-même dans le sens du test classique, donc je ne peux pas dire "moi! Moi! Je le fais!". Je suppose que la question est de se demander "quelles industries / entreprises utilisent le TDD dans tous les domaines" plutôt que "quelqu'un peut-il introduire le TDD dans sa vie quotidienne?". Je suis d'accord qu'un développeur individuel peut totalement faire TDD sans forcer l'ensemble du groupe à le faire, je ne pense pas que c'était le point de la question.

Mon impression en écoutant l'industrie est que vous êtes plus susceptible de voir TDD dans la plupart des groupes de développement d'une entreprise dans les situations où:

• Il n'y a pas de grande base de code existante avant la création de TDD

• L'entreprise n'est pas énorme et n'a donc pas beaucoup de répit «nous l'avons toujours fait dans l'autre sens».

• L'entreprise n'a pas une énorme adhésion au processus formalisé. Cela ne veut pas dire que vous ne pouviez pas implémenter TDD dans, par exemple, une entreprise certifiée CMMI - mais si vous aviez un processus non-TDD, obtenir tous les processus que vous surveillez avec CMMI mis à jour peut être un investissement majeur.

• Les tests peuvent être scriptés - il s'agit des bases de code les plus complexes, car même si vous ne pouvez pas facilement scripter la couche la plus proche de l'utilisateur, vous pouvez scripter certains des éléments internes. Mais je considère les situations avec des options bien développées pour l'automatisation des tests comme les points les plus agréables pour TDD, car elles sont basées sur la relance et la non-rupture de toute une batterie de tests où vous avez besoin de commentaires sur les tests très rapidement. Ma pensée est qu'une application web autonome est une bonne cible TDD, un système avec une intégration ou une entrée COTS majeure qui n'est pas basée sur l'interface graphique peut être délicat.

• Systèmes à l'état non prototypé. Idéalement, la prochaine grande version après le prototype - où la preuve de concept est terminée et le projet est financé, mais tout le monde sait que la prochaine tentative doit sauter en qualité.

• Parties prenantes qui sont investies dans le processus.

J'ai essayé dans la mesure du possible - mais je pense que c'est vraiment dû à l'environnement d'entreprise dans lequel vous vous trouvez. J'ai travaillé dans l'industrie des jeux pendant de nombreuses années (en tant qu'artiste btw), et il n'y avait pas de concept de TDD - juste une approche de QA par force brute. Je suis passé au développement Web et je n'ai pas encore travaillé dans une agence avec une reconnaissance formelle (ou une connaissance de ...) des tests unitaires / TDD. Il en va de même pour la plupart de mes pairs de l'industrie, qui travaillent dans un large éventail de disciplines.

Dans une agence axée sur les ventes, TDD offre très peu de retour sur investissement à court terme au client, et il est donc difficile de vendre aux supérieurs hiérarchiques lors de la définition d'un projet. Cependant, plus un projet prend de l'ampleur, plus il devient convaincant.

Étant donné que des livres comme Death March indiquent un phénomène répandu, c'est-à-dire une industrie en proie à un développement "crunch" et "milestone" - je parie que TDD est probablement rare en dehors des startups bien financées ou des magasins d'entreprise monolithiques. Ce n'est pas que les gens là-bas ne croient pas en la valeur du TDD - mais c'est trop abstrait pour vendre à leurs clients.

J'essaye d'entrer dans TDD moi-même. Je pense que tant que vous suivez des itinéraires que vous connaissez déjà (le travail quotidien), c'est plutôt simple. Mais je ne peux tout simplement pas faire le tour des tests pour les parties de l'interface utilisateur ou lorsque vous devez trouver une nouvelle solution à un problème que vous n'avez pas rencontré auparavant. Ou en utilisant un framework que vous ne connaissez pas.

Donc je suppose que vous devez faire une sorte de LearningTests, des preuves de concepts séparées et les réécrire ensuite, etc. ou je me trompe?

Et (je sais que c'est un ancien mais je n'ai encore vu aucune bonne réponse): comment codez-vous les algorithmes en utilisant TDD (quand les résultats peuvent être trop complexes pour vraiment "s'affirmer" avec facilité)?

Je peux vraiment voir les côtés positifs de TDD et im sur le bateau, mais c'est très difficile pour les débutants lorsque le code que vous écrivez vous prend presque le double du temps (et vous avez des pairs qui ne voient pas du tout les pros et se moquent de vous avec RAD)

J'ai essayé plusieurs fois et cela a très bien fonctionné. Malheureusement, la plupart du temps, si je peux tester manuellement mon application, je reporte les tests unitaires jusqu'à ce que je me sente trop ennuyé pour implémenter autre chose ou qu'il y ait un bug que je ne peux pas facilement résoudre.

Je le fais. L'avancement de nos user stories est suivi sur un tableau Kanban, qui a un "Has a Test?" colonne à gauche (en amont) de Développement.

Cette disposition quelque peu inhabituelle rend une politique explicite: un test d'acceptation automatisé défaillant (généralement, quelques-uns d'entre eux) doit exister. Il doit être traçable selon les besoins du client. Les tests d'acceptation découlent de conditions de satisfaction , qui résultent de conversations qui commencent par une carte d'histoire . J'anime des ateliers réguliers où nous réfléchissons aux exigences, identifions les lacunes et découvrons les principaux tests d'acceptation qui garantissent que la valeur pour l'utilisateur est délivrée lorsqu'ils réussissent (la définition de fait ). C'est une activité collaborative impliquant des programmeurs, des analystes commerciaux et parfois des testeurs.

La boucle de rétroaction des tests d'acceptation est assez longue: cela peut prendre plusieurs jours pour terminer l'histoire. Le développement possède ses propres boucles de rétroaction TDD plus courtes.

"[... pas de style test-first ...] Plus semblable à Agile ...."

Il s'agit d'une fausse représentation complète d'Agile. La définition de done est un élément clé d'Agile et l'un des piliers sur lequel elle repose est le test d'acceptation automatisé (ce que j'ai décrit ci-dessus est une façon de le faire.) Si la programmation extrême (XP) est utilisée comme méthode d'implémentation Agile, alors ATDD / BDD et TDD sont prescrits.

Je le fais, mais généralement uniquement pour les composants non ui, et quand je sais que je ne peux pas garder l'intégralité de l'algorithme d'un module dans ma tête en même temps, ou quand le module est une nouvelle partie du système sur lequel je travaille, donc je ne peux pas compter sur la majorité des bibliothèques que j'utilise pour avoir été hautement déboguée.

Essentiellement, je le fais lorsque la complexité des exigences signifie que je pourrais autrement me perdre dans le code.

C'est une habitude difficile à démarrer et qui nécessite l'adhésion de la direction, mais lorsque vos tests commencent à s'arrêter à mi-chemin du développement, cela peut vous sauver la vie!

Je voulais poser cette question même, pour voir combien d'entreprises pratiquaient effectivement le TDD.

Au cours des 11 années que j'ai programmées professionnellement, seules les deux dernières organisations étaient même au courant du TDD (qui s'étend sur près de 5 ans d'esprit, avant cette période, le TDD n'était pas aussi populaire qu'aujourd'hui). Je vais aller droit au but et répondre à votre question avant de m'éloigner de mon argumentaire de vente pour TDD :)

Dans la dernière entreprise pour laquelle je travaillais (éditeur universitaire en ligne de collections de sciences humaines et scientifiques), nous savions que nous devions pratiquer le TDD, mais nous n'y sommes jamais arrivés. Pour notre défense, nous avions une base de code de 250k, donc ajouter des tests à une base de code non testable de cette taille me semblait insurmontable (je me sens coupable de taper ça maintenant!). Même les meilleurs d'entre nous font des erreurs .

Quiconque a fait même une petite quantité de TDD sait à quel point les tests de mise à niveau sur du code non testable peuvent être douloureux ... Les principales causes sont les dépendances implicites (vous ne pouvez pas tirer sur tous les leviers pour affirmer les résultats du code - vous ne pouvez pas vous moquer scénarios) et la violation du principe de responsabilité unique (les tests sont compliqués, artificiels, nécessitent trop de configuration et sont difficiles à comprendre ).

Nous avons temporairement augmenté notre équipe QA (d'une, peut-être deux personnes à une demi-douzaine ou plus) pour tester la plate-forme avant toute version. C'était extrêmement coûteux en temps et en argent, certaines versions prenaient trois mois pour terminer les «tests». Même alors, nous savions que nous livrions avec des problèmes, ils n'étaient tout simplement pas des «bloqueurs» ou «critiques», juste «haute priorité».

Si vous avez une expérience commerciale de plusieurs années, vous apprécierez que chaque entreprise affirme des tâches critiques , puis invente un niveau de priorité plus élevé au-dessus de cela, et très probablement au-dessus de cela aussi - en particulier lorsque quelqu'un d'en haut pousse une fonctionnalité / correction de bogue. Je digresse ...

Je suis heureux d'annoncer que je pratique le TDD dans mon entreprise actuelle (télécommunications, maison de développement d'applications Web et mobiles), couplé à Jenkins CI pour fournir d'autres rapports d'analyse statique (la couverture de code étant la plus utile après avoir confirmé la réussite de la suite de tests) . Les projets sur lesquels j'ai utilisé TDD sont un système de paiement et un système informatique de grille.

L'argumentaire de vente ...

Il peut souvent être difficile de justifier des tests automatisés pour les membres non techniques de l'équipe. L'écriture de tests ajoute plus de travail au processus de développement mais ... le temps que vous investissez dans les tests maintenant, vous économiserez plus tard dans les efforts de maintenance. Vous empruntez vraiment du temps . Plus le produit est utilisé longtemps, plus vous réaliserez d'économies - et cela vous aidera à éviter une réécriture importante .

Tester d'abord signifie que vous codez d'abord votre intention, puis confirmer que votre code remplit cette intention. Cela fournit une concentration et distille votre code pour ne faire que ce qui est prévu et pas plus (lire sans ballonnement). C'est une spécification et une documentation exécutables en même temps (si votre test est bien écrit et que les tests doivent être aussi lisibles / propres que votre code système, sinon plus!).

Les non-programmeurs n'auront (souvent) pas cette idée et donc TDD n'a pas beaucoup de valeur pour eux, et est considéré comme un raccourci jetable vers une date de sortie antérieure.

La programmation est notre domaine, et dans mon esprit, il nous appartient , en tant que professionnels, de conseiller sur les meilleures pratiques comme TDD. Ce n'est pas aux chefs de projet de décider si c'est fait pour réduire le temps de développement, c'est hors de leur juridiction . De la même manière, ils ne vous disent pas quel cadre, solution de mise en cache ou algorithme de recherche utiliser, ils ne devraient pas vous dire si vous devez utiliser des tests automatisés.

À mon avis, l'industrie du développement de logiciels (dans l'ensemble) est actuellement en panne, le fait que les tests de vos logiciels ne soient PAS la norme.

Imaginez cela dans d'autres industries: médical, aviation, automobile, cosmétiques, peluches, boissons alcoolisées, etc. J'ai demandé à ma fiancée de nommer une industrie où elle ne teste pas le produit et elle ne pouvait pas!

Il est peut-être injuste de dire qu'aucun test ne se produit parce qu'il le fait ... mais dans les entreprises sans test automatisé, c'est un processus très manuel / humain (lu maladroit et souvent sujet aux erreurs).

Un point que je soutiendrais dans votre question ...

Ils voulaient généralement que le développement commence immédiatement, ou après un court séjour de conception. Plus semblable à Agile.

Être "Agile" ne prescrit pas de procéder sans tests, le premier membre répertorié sur agilemanifesto.org est Kent Beck , le créateur de XP et TDD!

Deux livres que je recommanderais fortement si vous êtes intéressé par TDD, ou si vous ne les avez tout simplement pas lus et que vous êtes un programmeur passionné (c'est tout le monde qui lit bien?;)

Développement d'un logiciel orienté objet guidé par des tests

Clean Code - Série Robert C Martin ("Uncle Bob")

Ces deux livres se complètent et condensent beaucoup de sens en quelques pages.

Merci d'avoir posé cette question :)

Ceux qui implémentent des clones. Je ne peux pas penser à un meilleur processus lorsque vous développez quelque chose, qui fonctionne exactement comme un programme existant.

Évidemment, c'est un cas assez inhabituel, mais les développeurs de SQLite utilisent largement les tests. (Je suppose que leur processus de développement est d'abord un test, bien que je ne sois pas sûr.)

• 73 000 lignes de code
• 91 378 600 lignes de code de test

Voir http://www.sqlite.org/testing.html