Pour provoquer (mais c’est toi qui a commencé :-))je te dirais que ce qui est du bullshit ce sont les tests unitaires quand on peut faire des tests d’acceptation en bdd. 80% des tests unitaires ne servent a rien si ce n’est a tester que le développeur se comprend lui même. Les vrais tests utiles sont ceux qui permettent de vérifier la cohérence entre ce que veut le client et ce qu’écrit le codeur d’ou le BDD et Cucumber.

On ne fait pas du bdd parce que c’est élégant mais parce que c’est un langage de communication commun entre le client métier et la technique. Cela te semble moins important que d’améliorer un gestionnaire de version mais pour avoir un peu d’expérience dans ce métier je sais que le manque de compréhension entre donneur d’ordre et développeurs est le facteur numéro 1 d’échec ou de retard des projets et donc de procès.

L’objectif n’est pas qu’un non technicien puisse comprendre les tests mais qu’un expert du métier puisse formaliser en collaboration avec un technique son savoir souvent implicite pour le rendre compréhensible avec des critères d’acceptation mesurables donc objectifs.

Après sur le coté de l’implémentation de cucumber si tu penses que devoir écrire 2 fichiers différents est un problème je ne vois pas vraiment pourquoi parce que ce sont deux choses différentes d’un coté les spécifications en gherkin et de l’autre l’écriture du test. A moins que tu travailles sans spécifications et n’écrive que des tests l’avantage en terme de temps de cucumber c’est que spécifications et tests soient synchronisés parce que les spécifications en UML dans un beau document word qui est dépassé a la minute même ou le développeur commence a coder me semble être bien plus problèmatique et un gaspillage de temps bien plus important.

Je suis parti par là ——————–>

Utilise mercurial, c’est comme git mais en simple et en python

“Bumbo Bumbo, petite automobile, bile, tu parrais si agile, gile, sous ton drôle de capot, bum bum bumbo…”

Merci de ces retours, ils sont forts pertinents.

Il y a beaucoup de bullshit et de hype autour de cucumber, clairement. Que le client écrive les scenarios c’est de la connerie en effet. Surtout que de toute façon, rédiger les scenarios n’est pas anodin en terme de rédaction, surtout pour se focaliser sur l’aspect business.

Par contre,
L’intérêt est essentiellement de présenter le fonctionnement de l’application sous un aspect compréhensible par le client. Si je lui montre mes scénarios, il peut dire, oui c’est bien comme cela que cela doit fonctionner. Et ça c’est intéressant. C’est plus rapide pour lui de jeter un oeil aux scénarios que je lui présente que d’aller tester dans l’application à chaque features. Bien entendu, il testera à chaque milestone, mais cela lui donne quand même un document facile à comprendre à accepter, qui de plus est, basé directement sur le fonctionnel de l’application.

Oui, c’est un outil qui prends un petit moment à appréhender. Le DSL “foireux”, ça me parait un agressif, à part When, Then, Given il n’y a rien d’autres que ce que toi tu définis.
Peux tu préciser le fond de te pensée, que je comprenne mieux ce que tu y reproches ?

Pour ce qui est de l’exemple sur les factorielles, que veux-tu, c’est un exemple. L’auteur ne va pas écrire un projet entier pour aller démontrer comment cela fonctionne …

Après, je pense qu’il faut prendre le truc autrement vis à vis des tests. Certes, ceux qui veulent imposer le TDD ou BDD à tous sont aussi dogmatiques que les fanatiques scrums qui t’expliquent que ça marchait pas avant ™ et que ça ira mieux maintenant. Mais après, il y a des gens qui écrivent les tests en premiers, et même qui font du cucumber. J’en connais un paquet dans mon entourage. Parfois, on écrit le code avant quand le test serait trop chiant. Bref, ya pas de religion là dedans, quand tu te concentres sur le seul aspect intéressant, “produire”.

Mais le fait que personne ne s’en serve n’est pas un argument valide pour dire que quelque chose est inutile.