Le test ne fait pas partie de la preuve. La preuve permet de s'assurer que les tests des cas de base assurent la validité d'éventuels tests pour toutes les valeurs possible. Dans ce cas tu ne peux plus dire "qu'ils ne testent qu'un lot précis d'entrées...".
Maintenant, beaucoup de fonctions ne peuvent pas être prouvées correctes : basiquement si tu utilises
Mais généralement c'est déjà un bénéfice énorme.
Un sanity check complet ça veut dire que tu reteste toute la base de code à chaque fois que tu fais une modif. ça veut dire par exemple que tu t'assure que tes modifs n'ont pas de répercussion causant une régression sur un volet totalement différent de ton appli, ça ce sont les bug les plus chiants mais généralement si on est propre il n'y en a pas.
Ou si tu as touché à plein d'endroits dans le code tu valides plein de modifs d'un coup.
Ou bien tu as accepté un commit et tu vérifies qu'il fout pas la grouille.
Ou bien tu testes sur 40 plateformes/VM différentes et tu as la flemme de faire toutes tes VM à la main et ne dormir que deux minutes par nuit.
ça te permet aussi de fournir le test pour une interface. Par exemple en erlang l'interface dict permet de créer des modules gérant des hashmaps : tu as dict, orddict, gb_tree, rb_tree. Selon les données, leur quantité, tu as des modules de plus en plus spécialisés. Et quand tu veux en créer un nouveau, tu prends la doc de l'interface + le test afin de valider rapidement ton code.
D'ailleurs en OO ce sont les interfaces qui sont testées au final. Beaucoup sont partisans de ne pas tester les méthodes privates.
Perso c'est ça qui me plaît le plus : j'ai pour habitude d'écrire du code en utilisant une API qui n'existe pas encore. ça permet de voir ce qui est pratique ou non, ce qui est relou à répéter, à réécrire, les endroits où on veut pouvoir spécifier des options, etc.
ça te rappelle quelque chose ? Et oui, tout le monde fait ça, et pourquoi ? parce qu'il faut bien tester ce qu'on écrit, au moins une fois, afin de voir si on suit le bon chemin.
Le TDD c'est simplement l'automatisation et la systématisation de ça sur l'ensemble de l'appli pour multiplier les bénéfices d'une simple tâche que tous les développeurs font : lancer son code.
Donc je ne vois pas pourquoi s'en passer, et rien ne t'oblige à avoir une couverture à 100% ni d'utiliser aussi des preuves mathématiques quand tu le peux. (mais perso en FP la preuve mathématique à souvent la même gueule que le code lui-même donc c'est relou)
Maintenant, beaucoup de fonctions ne peuvent pas être prouvées correctes : basiquement si tu utilises
this c'est mort déjà. C'est pour ça qu'en OO les tests ne servent qu'à s'assurer qu'un objet d'une classe se comporte plus ou moins comme on le souhaite. (mais tu peux faire de l'OO avec plein de fonctions pures aussi).Mais généralement c'est déjà un bénéfice énorme.
Un sanity check complet ça veut dire que tu reteste toute la base de code à chaque fois que tu fais une modif. ça veut dire par exemple que tu t'assure que tes modifs n'ont pas de répercussion causant une régression sur un volet totalement différent de ton appli, ça ce sont les bug les plus chiants mais généralement si on est propre il n'y en a pas.
Ou si tu as touché à plein d'endroits dans le code tu valides plein de modifs d'un coup.
Ou bien tu as accepté un commit et tu vérifies qu'il fout pas la grouille.
Ou bien tu testes sur 40 plateformes/VM différentes et tu as la flemme de faire toutes tes VM à la main et ne dormir que deux minutes par nuit.
ça te permet aussi de fournir le test pour une interface. Par exemple en erlang l'interface dict permet de créer des modules gérant des hashmaps : tu as dict, orddict, gb_tree, rb_tree. Selon les données, leur quantité, tu as des modules de plus en plus spécialisés. Et quand tu veux en créer un nouveau, tu prends la doc de l'interface + le test afin de valider rapidement ton code.
D'ailleurs en OO ce sont les interfaces qui sont testées au final. Beaucoup sont partisans de ne pas tester les méthodes privates.
(26-08-2013, 02:06 PM)Sephi-Chan a écrit : Ils me servent à documenter ce que je veux obtenir avant d'avoir écrit l'implémentation de cette chose.
Ça permet donc de piloter la conception de mon code et de détecter des régressions introduites par un refactoring.
Perso c'est ça qui me plaît le plus : j'ai pour habitude d'écrire du code en utilisant une API qui n'existe pas encore. ça permet de voir ce qui est pratique ou non, ce qui est relou à répéter, à réécrire, les endroits où on veut pouvoir spécifier des options, etc.
ça te rappelle quelque chose ? Et oui, tout le monde fait ça, et pourquoi ? parce qu'il faut bien tester ce qu'on écrit, au moins une fois, afin de voir si on suit le bon chemin.
Le TDD c'est simplement l'automatisation et la systématisation de ça sur l'ensemble de l'appli pour multiplier les bénéfices d'une simple tâche que tous les développeurs font : lancer son code.
Donc je ne vois pas pourquoi s'en passer, et rien ne t'oblige à avoir une couverture à 100% ni d'utiliser aussi des preuves mathématiques quand tu le peux. (mais perso en FP la preuve mathématique à souvent la même gueule que le code lui-même donc c'est relou)