Mon expérience : tous les tests maintenus en dehors du code sont condamnés à devenir obsolètes et non maintenus.
Je ne suis pas d'accord. Si ces tests font parti de ton flow d'intégration continue, je ne vois pas pourquoi ils ne seraient pas maintenu (puisque cela casserait ton build).
Enfin, même si ce n'est pas du code, on voit très rapidement que les non techniciens ne sont pas capables de générer des tests solides et pérennes. Et ne sont pas autonomes. C'est vrai également avec du Cucumber ; la personne avec la compétence fonctionnelle/métier doit forcément travailler en paire avec un technicien à l'aise avec l'outil de test, qui va le guider sur ce qui est possible/pas possible, lui créer des squelettes de tests, etc.
La démarche peut aller jusqu'à 3 amis même. La démarche BDD permet à un fonctionnel de lire et comprendre les cas de tests et donc aide énormément à leur maintiens. Et c'est une documentation plus accessible que le code de test pour le développeur. Enfin la mise à jour ou les ajouts de cas de tests peuvent être suffisamment simple.
Bref ça a du sens surtout dans une optique de DDD (oui ça fait beaucoup de *DD).
[^] # Re: Utilisation
Posté par barmic 🦦 . En réponse à la dépêche Cerberus 4.7 — En route pour la webperf et l’analyse web. Évalué à 3.
Je ne suis pas d'accord. Si ces tests font parti de ton flow d'intégration continue, je ne vois pas pourquoi ils ne seraient pas maintenu (puisque cela casserait ton build).
La démarche peut aller jusqu'à 3 amis même. La démarche BDD permet à un fonctionnel de lire et comprendre les cas de tests et donc aide énormément à leur maintiens. Et c'est une documentation plus accessible que le code de test pour le développeur. Enfin la mise à jour ou les ajouts de cas de tests peuvent être suffisamment simple.
Bref ça a du sens surtout dans une optique de DDD (oui ça fait beaucoup de *DD).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll