Cela s’applique même avec des changements d’interface.
Cette discipline facilite même le changement d’interface. En pratique, l’interface change durant l’implémentation. Au début, elle est très simple. Au fil des ajouts de comportement, l’interface s’étoffe.
Ici l’interface n’est pas l’interface utilisateur, où il n’y a pas de tests automatisés. La discipline du TDD n’est pas applicable, car on ne connaît pas le résultat à l’avance. Il est possible d’adjoindre des tests via des screenshot, avec des outils comme chromatic.com.
Perso, si je veux voir des exemples, je vais voir les tests.
L’avantage, c’est une documentation exécutable, elle ne peut pas mentir.
Il y a des exceptions
- Comme la documentation de l’architecture.
Elle est couverte partiellement par les tests d’intégrations. - Comme la documentation des conventions de code utilisé.
Bien que ce soit le code lui-même qui sert d’exemple.
Et que cela peut être automatisé, avec des outils comme php-cs-fixer.
Pense qu’il y a une minute, la suite de teste passée.
Au lieu de débuger, tu annules les derniers changements. Puis essaye autre chose.
C’est bien plus rapide que de placer des console.log dans ton code.
Je te rejoins, c’est de bonnes ressources que tu partages pour faire ouvrir les yeux aux développeurs.
Je comprends entièrement pourquoi tu ne l’aimes pas, car elle est mal comprise.
Je comprends aussi, que des gens essaient de trouver de nouvelles manières de présenter en partant de cette incompréhension de base. C’est comme mettre un pansement sur une jambe de bois.
Les tests unitaires ne sont pas : des tests pour toutes les classes, toutes les méthodes et pour toutes les fonctions.
Quand un développeur logiciel le comprend, alors c’est le déclic.
La pyramide change de sens dans sa tête et se rapproche de ce que j’ai présenté plus haut.
