Du coup, pour détecter une merde dans le déploiement c'est assez pratique, je dois l'avouer, alors qu'il ne me semble pas que le TDD permette de vérifier que le problème vienne de l'installation de ton application, puisque les tests ne sont pas inclus dans le binaire (je ne crache pas sur TDD, au contraire, je ne fais que demander ce que tu en penses).
Le TDD n'empêche évidemment pas de mettre des assertions dans le code, ainsi que des logs, qui sont en effet bien plus indiqués pour vérifier que l'installation est correcte.
j'imagine que tu peux comprendre qu'écrire 4 fois plus de code de test par classe que de code réel me semble trop lourd.
Je peux le comprendre, et ta façon de penser est naturelle pour quelqu'un n'ayant pas pratiqué le TDD. Mais là où tu te trompes c'est qu'on s'en fout du nombre de lignes, ce qui compte c'est le temps que tu mets à écrire ta feature correctement (si tu torches un code vite fait plein de bugs, il faut compter tout le temps de debug, ainsi que le temps que tes collègues ont perdu etc…).
Je t'ai donné un vrai exemple tiré de mon expérience ; mon collègue pensait réellement gagner du temps en n'écrivant pas de test. La réalité c'est que j'ai quand même écrit plus de code utile que lui pendant le même temps (le nombre de lignes de code n'est pas une super métrique, mais en l'occurrence mon code était bien factorisé et objectivement bien meilleur pour le même prix).
Sachant que la moyenne de mes méthodes ne dépasse pas les 15 lignes (mes "algorithmes" se situent en fait plus dans le diagramme de classes, chacun s'occupant uniquement de ses affaires. Ca n'évite pas les bugs, mes le code est plus lisible pour moi, et 20 fois plus simple à réutiliser),
Tu n'a pas à te dévaloriser parce que tes fonctions font rarement plus de 15 lignes : c'est normal et c'est pareil pour la plupart des gens ; ou bien ça devrait l'être, et la super fonction de la mort de 300 lignes peut être réécrite proprement en 20. Quant à écrire du code objet bien modulaire, là encore c'est en parfaite accord avec le TDD, où tu es obligé, si tu le fais bien, à écrire du code facilement testable.
En te fournissant un filet de sécurité permanent, tu en viens à refactorer ton code en permanence sans avoir peur des régressions (le fameux syndrome du "ça marche je n'y touche plus"). C'est vraiment très agréable, et ça a complètement changer ma vision du code, sans exagérer. Écrire les tests après c'est vraiment pénible, mais les écrire en même temps est amusant (mais il faut essayer c'est difficile à croire).
Le principe me semble réellement intéressant, mais la quantité de code de tests à écrire au début de l'application me semble quand même vachement excessive
Oui il m'arrive lorsque j'écris un prototype/proof of concept de ne pas le faire en TDD, mais le faire lorsque l'essai est transformé (et écrire alors les tests pour le "vieux" code à posteriori). Ce n'est pas un dogme non plus :)
[^] # Re: Pas de révision d'historique
Posté par GuieA_7 (site web personnel) . En réponse au journal Chiselapp ferme ses portes. Évalué à 1.
Le TDD n'empêche évidemment pas de mettre des assertions dans le code, ainsi que des logs, qui sont en effet bien plus indiqués pour vérifier que l'installation est correcte.
Je peux le comprendre, et ta façon de penser est naturelle pour quelqu'un n'ayant pas pratiqué le TDD. Mais là où tu te trompes c'est qu'on s'en fout du nombre de lignes, ce qui compte c'est le temps que tu mets à écrire ta feature correctement (si tu torches un code vite fait plein de bugs, il faut compter tout le temps de debug, ainsi que le temps que tes collègues ont perdu etc…).
Je t'ai donné un vrai exemple tiré de mon expérience ; mon collègue pensait réellement gagner du temps en n'écrivant pas de test. La réalité c'est que j'ai quand même écrit plus de code utile que lui pendant le même temps (le nombre de lignes de code n'est pas une super métrique, mais en l'occurrence mon code était bien factorisé et objectivement bien meilleur pour le même prix).
Tu n'a pas à te dévaloriser parce que tes fonctions font rarement plus de 15 lignes : c'est normal et c'est pareil pour la plupart des gens ; ou bien ça devrait l'être, et la super fonction de la mort de 300 lignes peut être réécrite proprement en 20. Quant à écrire du code objet bien modulaire, là encore c'est en parfaite accord avec le TDD, où tu es obligé, si tu le fais bien, à écrire du code facilement testable.
En te fournissant un filet de sécurité permanent, tu en viens à refactorer ton code en permanence sans avoir peur des régressions (le fameux syndrome du "ça marche je n'y touche plus"). C'est vraiment très agréable, et ça a complètement changer ma vision du code, sans exagérer. Écrire les tests après c'est vraiment pénible, mais les écrire en même temps est amusant (mais il faut essayer c'est difficile à croire).
Oui il m'arrive lorsque j'écris un prototype/proof of concept de ne pas le faire en TDD, mais le faire lorsque l'essai est transformé (et écrire alors les tests pour le "vieux" code à posteriori). Ce n'est pas un dogme non plus :)