Le développement piloté par les tests m'oblige-t-il à suivre SOLID?

J'entends beaucoup de praticiens TDD dire que l'un des avantages de TDD est qu'il oblige les développeurs à suivre les principes SOLIDES (responsabilité unique, ouvert-fermé, substitution Liskov, ségrégation d'interface et inversion de dépendance). Mais pour moi il suffit d'écrire quelques tests (test unitaire principalement) pour comprendre qu'il est important de suivre SOLID (et donc de créer une architecture testable).

TDD oblige-t-il les développeurs à suivre SOLID plus activement que de simplement écrire des tests unitaires?

Tout d'abord, TDD ne vous oblige pas strictement à écrire du code SOLIDE. Vous pouvez faire TDD et créer un gros gâchis si vous le souhaitez.

Bien sûr, connaître les principes SOLID aide, car sinon vous risquez de ne pas avoir une bonne réponse à beaucoup de vos problèmes, et donc d'écrire du mauvais code accompagné de mauvais tests.

Si vous connaissez déjà les principes SOLID, TDD vous encouragera à y penser et à les utiliser activement.

Cela dit, il ne couvre pas nécessairement toutes les lettres de SOLID , mais il vous encourage fortement et vous encourage à écrire au moins partiellement du code SOLID, car cela rend les conséquences de ne pas le faire immédiatement visibles et ennuyeuses.

Par exemple:

1. Vous devez écrire du code découplé pour pouvoir vous moquer de ce dont vous avez besoin. Cela prend en charge le principe d'inversion de dépendance .
2. Vous devez écrire des tests clairs et courts afin de ne pas avoir à trop changer dans les tests (ce qui peut devenir une grande source de bruit de code si vous le faites autrement). Cela soutient le principe de responsabilité unique .
3. Cela peut être discuté, mais le principe de ségrégation des interfaces permet aux classes de dépendre d'interfaces plus légères qui rendent la simulation plus facile à suivre et à comprendre, car vous n'avez pas à vous demander "Pourquoi ces 5 méthodes n'ont-elles pas été également moquées?", Ou encore plus important, vous n'avez pas beaucoup de choix lorsque vous décidez de la méthode à moquer. C'est bien lorsque vous ne voulez pas vraiment parcourir tout le code de la classe avant de le tester, et utilisez simplement les essais et les erreurs pour obtenir une compréhension de base de son fonctionnement.

L'adhésion au principe Open / Closed peut bien aider les tests écrits après le code, car il vous permet généralement de remplacer les appels de service externes dans les classes de test qui dérivent des classes testées. Dans TDD, je pense que ce n'est pas aussi exigé que d'autres principes, mais je peux me tromper.

Adhérer à la règle de substitution Liskov est idéal si vous souhaitez minimiser les modifications pour que votre classe reçoive une instance non prise en charge qui arrive simplement à implémenter la même interface de type statique, mais il est peu probable que cela se produise dans les cas de test appropriés parce que vous êtes ne va généralement pas passer de classe sous test les implémentations réelles de ses dépendances.

Plus important encore, les principes SOLID ont été conçus pour vous encourager à écrire du code plus propre, plus compréhensible et plus facile à entretenir, tout comme TDD. Donc, si vous faites TDD correctement et que vous faites attention à l'apparence de votre code et de vos tests (et ce n'est pas si difficile parce que vous obtenez des commentaires immédiats, de l'API et de l'exactitude), vous vous inquiétez moins des principes SOLID, en général.

Non

TDD peut faciliter le respect des bonnes pratiques en raison du refactoring continu, mais il ne vous oblige à suivre aucun principe. Tout ce qu'il fait est de s'assurer que le code que vous écrivez est testé. Vous pouvez suivre les principes que vous aimez lorsque vous écrivez du code pour satisfaire le test; ou pas de principes du tout.

Ma compréhension des principes SOLID s'est élargie d'un ordre de grandeur lorsque j'ai commencé à faire du TDD. Dès que j'ai commencé à réfléchir à la façon de se moquer des dépendances, j'ai réalisé que pratiquement chaque composant de la base de code avait une implémentation alternative potentielle. Et combien il est plus facile de tester une simple API publique.

Il a également permis de mieux comprendre la plupart des modèles de conception. Surtout le modèle de stratégie.

Oui : TDD est principalement une bonne technique de conception (et seulement secondaire une technique de test). Cela aide beaucoup à atteindre les principes solides, bien que des exemples (pathologiques) de TDD avec beaucoup d'odeurs de code soient toujours possibles.

La connexion entre TDD et les principes solides est contestée (avec la conclusion ci-dessus) dans ce grand podcast hanselminute intitulé "Le développement piloté par les tests est la conception - Le dernier mot sur TDD" .