Pourquoi le développement piloté par les tests est-il absent du test de Joel?

Je lisais ce blog de Joel Spolsky sur environ 12 étapes pour améliorer le code . L'absence de Test Driven Development m'a vraiment surpris. Je veux donc poser la question aux gourous. Le TDD ne vaut-il pas vraiment la peine?

Le développement piloté par les tests était pratiquement inconnu avant la publication du livre de Kent Beck en 2002, deux ans après que Joel ait écrit ce post. La question devient alors pourquoi Joel n'a-t-il pas mis à jour son test, ou si TDD avait été mieux connu en 2000, l'aurait-il inclus parmi ses critères?

Je crois qu'il ne l'aurait pas, pour la simple raison que l'important est que vous ayez un processus bien défini, pas les détails spécifiques de ce processus. C'est la même raison pour laquelle il recommande le contrôle de version sans spécifier un système de contrôle de version spécifique, ou recommande d'avoir une base de données de bogues sans recommander une marque spécifique. Les bonnes équipes s'améliorent et s'adaptent continuellement, et utilisent des outils et des processus qui correspondent bien à leur situation particulière à ce moment particulier. Pour certaines équipes, cela signifie définitivement TDD. Pour les autres équipes, pas tellement. Si vous adoptez le TDD, assurez-vous qu'il ne sort pas d'une mentalité de culte du fret .

Joel a effectivement abordé cette question spécifiquement à quelques endroits.

Il a expliqué que les choses que les tests ne sont pas capables d'attraper beaucoup de problèmes importants, en particulier subjectifs tels que "l'interface utilisateur de ce logiciel est-elle nul?" Selon lui, la dépendance excessive à l'égard des tests automatisés chez Microsoft est la raison pour laquelle nous nous sommes retrouvés avec Windows Vista.

Il a écrit comment, selon son expérience, les types de bogues que les utilisateurs trouvent réellement ont tendance à se diviser en deux catégories: 1) ceux qui apparaissent dans l'utilisation courante, que les programmeurs se seraient trouvés s'ils avaient exécuté leur propre code avant de l'utiliser , ou 2) des cas de bord si obscurs que personne n'aurait pensé à écrire des tests pour les couvrir en premier lieu. Il a déclaré que seul un très faible pourcentage des bogues que lui et son équipe corrigent dans FogBugz sont le genre de chose que les tests unitaires auraient détectés. (Je ne trouve pas cet article maintenant, mais si quelqu'un sait de quel article je parle, n'hésitez pas à modifier le lien ici.)

Et il a écrit comment cela peut être plus difficile que cela ne vaut, en particulier lorsque votre projet se transforme en un très grand projet avec de nombreux tests unitaires, puis vous changez quelque chose (intentionnellement) et vous vous retrouvez avec un très grand nombre de tests unitaires interrompus. Il utilise spécifiquement les problèmes que les tests unitaires peuvent causer comme raison pour laquelle il ne l'a pas ajouté comme un 13ème point au test Joel, même lorsque les gens suggèrent qu'il devrait le faire.

Joel Spolsky lui-même a répondu à cette question en 2009 :

Joel: Il y a un débat sur le développement piloté par les tests ... si vous avez des tests unitaires pour tout, ce genre de choses ... beaucoup de gens m'écrivent, après avoir lu le test de Joel, pour dire: "Vous devriez avoir un 13 chose ici: tests unitaires, tests unitaires à 100% de tout votre code. "

Et cela me semble être un peu trop doctrinaire sur quelque chose dont vous n'avez peut-être pas besoin. Par exemple, l'idée de la programmation agile n'est pas de faire les choses avant d'en avoir besoin, mais de les mettre en page au besoin. J'ai l'impression que les tests automatisés de tout, souvent, ne vont tout simplement pas vous aider. En d'autres termes, vous allez écrire énormément de tests unitaires pour vous assurer que le code qui va vraiment fonctionner, et vous allez certainement savoir si cela ne fonctionne pas [si vous ne le faites pas écrire les tests] fonctionne, en fait, fonctionne toujours, ... Je ne sais pas, je vais recevoir un tel mail de flamme pour cela parce que je ne l'exprime pas si bien. Mais je pense que si une équipe avait vraiment une couverture de code à 100% de ses tests unitaires, il y aurait quelques problèmes. Une, ils auraient passé énormément de temps à écrire des tests unitaires, et ils ne seraient pas nécessairement en mesure de payer ce temps en qualité améliorée. Je veux dire, ils auraient une certaine qualité améliorée, et ils auraient la possibilité de changer les choses dans leur code avec la confiance qu'ils ne cassent rien, mais c'est tout.

Mais le vrai problème avec les tests unitaires comme je l'ai découvert, c'est que le type de changements que vous avez tendance à faire à mesure que le code évolue a tendance à casser un pourcentage constant de vos tests unitaires. Parfois, vous apporterez une modification à votre code qui, en quelque sorte, casse 10% de vos tests unitaires. Intentionnellement. Parce que vous avez changé la conception de quelque chose ... vous avez déplacé un menu, et maintenant tout ce qui comptait sur ce menu était là ... le menu est maintenant ailleurs. Et donc tous ces tests se cassent maintenant. Et vous devez pouvoir entrer et recréer ces tests pour refléter la nouvelle réalité du code.

Donc, le résultat final est que, à mesure que votre projet devient de plus en plus grand, si vous avez vraiment beaucoup de tests unitaires, le montant d'investissement que vous devrez faire pour maintenir ces tests unitaires, les maintenir à jour et les garder leur passage, commence à devenir disproportionné au montant des avantages que vous en retirez.

Personne d'autre que Joel ne pouvait répondre à cela avec certitude. Mais nous pouvons essayer quelques raisons / observations.

Tout d'abord, les tests ne sont pas absents du test de Joel

• Les tests sont mentionnés deux fois en 12 étapes directement (10 et 12)
• L'existence d'une build est l'un des premiers points. L'idée d'avoir build est d'obtenir la capacité de voir si elles cassent, donc nous parlons (également) de tests ici.

Deuxièmement, l'idée du test Joel (si je comprends bien) est d'avoir des questions rapides, oui-non. "Tu fais du TDD?" ne rentrera pas exactement (la réponse pourrait être: "certains d'entre nous", "pour cette partie du code" ou "nous faisons des tests unitaires").

Troisièmement, je pense que personne n'a dit que (même Joel) que ces points où "les seuls valent le temps" (en passant, "programmez-vous" n'y figurent pas), juste que ce sont de bonnes questions rapides à poser en venant en contact avec une équipe logicielle, que ce soit en tant que futur membre de l'équipe ou même en tant que client - c'est une liste que j'ai donnée à des personnes non techniques autour de moi qui cherchaient des indices sur la qualité de leur propre service informatique. Ce n'est pas tout, mais c'est vraiment mauvais de battre en trois minutes.