Est-ce que «mise en œuvre évidente» de TDD signifie d'abord le code, puis le test?

Mon ami et moi sommes relativement nouveaux TDD et avons un différend sur la technique de "mise en œuvre évidente" (de "TDD par exemple" par Kent Beck). Mon ami dit que cela signifie que si l'implémentation est évidente, vous devriez aller de l'avant et l'écrire - avant tout test pour ce nouveau comportement. Et en effet, le livre dit:

Comment implémentez-vous des opérations simples? Il suffit de les mettre en œuvre.

Également:

Parfois, vous êtes sûr de savoir comment implémenter une opération. Aller de l'avant.

Je pense que ce que l'auteur veut dire, c'est que vous devez d'abord le tester, puis "l'implémenter" - par opposition au "Fake It ('Till You Make It)" et à d'autres techniques, qui nécessitent des étapes plus petites dans la phase de mise en œuvre. Aussi après ces citations, l'auteur parle de l'obtention de "barres rouges" (échec des tests) lors de la "mise en œuvre évidente" - comment obtenir une barre rouge sans test?.

Pourtant, je n'ai pu trouver aucune citation du livre disant "évident" signifie toujours tester d'abord.

Qu'est-ce que tu penses? Faut-il tester d'abord ou après quand l'implémentation est "évidente" (selon TDD, bien sûr)? Connaissez-vous un livre ou un article de blog disant exactement cela?

Je suis d'accord avec votre interprétation - c'est toujours Red Green Refactor, seulement avec le bit Refactor omis;)

Donc, écrivez d'abord un test qui échoue, puis implémentez la solution évidente au lieu de construire lentement une conception «la plus simple possible».

Connaissez-vous un livre ou un article de blog disant exactement cela?

Je dirais que le livre de Beck dit exactement cela.

Il poursuit en disant

Cependant, en utilisant uniquement l'implémentation évidente, vous exigez la perfection de vous-même. Psychologiquement, cela peut être une décision dévastatrice. Et si ce que vous écrivez n'est pas vraiment le changement le plus simple qui pourrait faire passer le test? Et si votre partenaire vous en montre une encore plus simple? Tu es un échec! Votre monde s'écroule autour de vous! Tu meurs. Vous vous figez.

Comment réussir le test en écrivant le code s'il n'existe pas avant le code?

Évidemment, il n'y a pas de règles strictes et rapides ici, nous étions agiles après tout, donc nous pouvons et devons nous adapter en itérant :)

Cela dépendra en partie de la simplicité d'utilisation, et au fur et à mesure que vous pratiquerez le TDD, vous trouverez régulièrement des choses que vous avez mal testées ou que vous n'avez pas vraiment testées du tout, tout cela fait partie de la courbe d'apprentissage.

N'oubliez pas non plus que TDD vous permet de tester l'interface et l'implémentation avant de la valider en code vivant.

Vous savez peut-être comment implémenter quelque chose, mais à quelle fréquence écrivez-vous une classe / méthode parfaite, etc. la première fois sans quelques ajustements en cours de route ou en parcourant le code une ou deux fois et six mois plus tard lorsque vous changez quelque chose, vous pouvez le faire avec plus de confiance et encore dans le bac à sable des tests.

Bien sûr, les tests ne signifient pas que vous écrivez le code plus correctement la première fois, mais vos modifications sont motivées par le test et les tests deviennent le premier client du code et, comme les tests sont très peu coûteux et, surtout, sans risque de modification vous avez plus de confiance et de liberté tout en vous développant.

Si vous essayez vraiment d'obtenir une bonne couverture et une meilleure qualité, choisissez d'abord plus de tests, car en pratiquant de plus en plus le TDD, vous développerez votre propre sentiment du niveau de couverture dont vous avez besoin.

J'ai appris que pour le code trivial, il ne devrait pas y avoir du tout.

exemple: si vous avez une méthode java getter / setter qui mappe une méthode à une variable locale, un plus indigne pour cela serait exagéré.

peut-être c'est ce que l'auteur veut dire

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."