L'approche "test d'écriture + refactorisation jusqu'au passage" est incroyablement anti-ingénierie.
Vous semblez avoir une idée fausse à la fois sur le refactoring et le TDD.
Le refactoring de code est le processus de modification du code source d'un programme informatique sans modification de son comportement fonctionnel externe afin d'améliorer certains attributs non fonctionnels du logiciel.
Ainsi, vous ne pouvez pas refactoriser le code tant qu'il n'est pas passé .
Et TDD, en particulier les tests unitaires (que je considère comme l’amélioration fondamentale, puisqu'un autre test me semble plutôt plausible), ne consiste pas à redéfinir un composant avant qu’il ne fonctionne. Il s'agit de concevoir un composant et de travailler sur la mise en œuvre jusqu'à ce que le composant fonctionne comme prévu.
En outre, il est important de bien comprendre que les tests unitaires consistent à tester des unités . En raison de la tendance à toujours écrire plein de choses à partir de zéro, il est important de tester de telles unités. Un ingénieur civil connaît déjà les spécifications des unités qu’il utilise (les différents matériaux) et peut s’attendre à ce qu’elles fonctionnent. Ce sont deux choses qui souvent ne s’appliquent pas aux ingénieurs en logiciel, et il est très ingénieux de tester les unités avant de les utiliser, car cela implique d’utiliser des composants testés et de haute qualité.
Si un ingénieur civil avait l’idée d’utiliser un nouveau tissu de fibres pour fabriquer un toit recouvrant un stade, vous devriez l’attendre à ce qu’il le teste en tant qu’unité, c’est-à-dire qu’il définisse les spécifications requises (par exemple poids, perméabilité, stabilité, etc.) et puis testez-le et affinez-le jusqu'à ce qu'il les rencontre.
C'est pourquoi TDD fonctionne. Parce que si vous construisez un logiciel avec des unités testées, les chances sont bien meilleures que cela fonctionne, si vous les connectez ensemble et si ce n’est pas le cas, vous pouvez vous attendre à ce que le problème se trouve dans votre code collé, en supposant que vos tests couvrent bien.
edit:
Refactoring signifie: pas de changement de fonctionnalité. Un des points de l’écriture du test unitaire est de s’assurer que le refactoring ne rompt pas le code. TDD est donc censé assurer que la refactorisation n’a pas d’effets secondaires.
La granularité n'est pas un sujet de perspective, car comme je l'ai dit, teste à l'unité les unités de test et non les systèmes, la granularité étant définie avec précision.
TDD encourage une bonne architecture. Cela vous oblige à définir et à mettre en œuvre les spécifications de toutes vos unités, ce qui vous oblige à les concevoir avant leur mise en œuvre, ce qui est tout le contraire de ce que vous semblez penser. TDD dicte la création d'unités, qui peuvent être testées individuellement et sont donc complètement découplées.
TDD ne signifie pas que je lance un test logiciel sur code spaghetti et agite les pâtes jusqu’à ce qu’elles passent.
Contrairement au génie civil, en génie logiciel, un projet évolue généralement en permanence. En génie civil, vous devez construire un pont en position A, pouvant transporter x tonnes et suffisamment large pour n véhicules par heure.
En génie logiciel, le client peut en principe décider à tout moment (éventuellement après l'achèvement des travaux) qu'il souhaite un pont à deux ponts et qu'il souhaite le connecter à l'autoroute la plus proche et qu'il souhaite qu'il s'agisse d'un pont levant, car son entreprise récemment commencé à utiliser des navires à voile.
Les ingénieurs en logiciel sont chargés de modifier les conceptions. Non pas parce que leurs conceptions sont défectueuses, mais parce que c'est le modus operandi. Si le logiciel est bien conçu, il peut être redessiné à un niveau élevé, sans avoir à réécrire tous les composants de bas niveau.
TDD consiste à concevoir un logiciel avec des composants hautement découplés testés individuellement. Bien exécuté, il vous aidera à répondre aux changements de besoins de manière significative, plus rapidement et plus sûrement que sans.
TDD ajoute des exigences au processus de développement, mais n'interdit aucune autre méthode d'assurance qualité. Certes, TDD n'offre pas la même sécurité que la vérification formelle, mais là encore, la vérification formelle est extrêmement coûteuse et impossible à utiliser au niveau du système. Et encore, si vous le vouliez, vous pourriez combiner les deux.
TDD englobe également des tests autres que les tests unitaires, effectués au niveau du système. Je trouve cela facile à expliquer mais difficile à exécuter et difficile à mesurer. En outre, ils sont tout à fait plausibles. Bien que je voie absolument leur nécessité, je ne les considère pas vraiment comme des idées.
En fin de compte, aucun outil ne résout réellement un problème. Les outils ne font que résoudre un problème plus facilement. Vous pouvez demander: Comment un ciseau m'aidera-t-il avec une belle architecture? Eh bien, si vous envisagez de faire des murs droits, les briques droites sont utiles. Et oui, d'accord, si vous donnez cet outil à un idiot, il le fera probablement claquer du pied, mais ce n'est pas la faute du burin, bien que ce ne soit pas un défaut de TDD de donner une fausse sécurité aux novices, qui n'écrit pas de bons tests.
En fin de compte, on peut dire que le TDD fonctionne beaucoup mieux que pas de TDD.