26-08-2013, 10:07 PM
haha je savais que tu proposerais comme exemple une liste si longue que le PC pète un câble. Malheureusement pour toi ça ne s'appelle pas prouver qu'un algorithme est correct ou non, ça s'appelle ne pas avoir un hardware adapté à ses besoins. Le théorème de Pythagore est prouvé mathématiquement mais si tu fais une fonction qui l'implémente et que tu lui balance un triangle avec des côtés trop grands ou je ne sais quoi ça ne signifie rien. Mathématiquement l'algorithme est toujours valide, c'est ton hardware qui ne sait pas le gérer. Quant au dépassement d'entier c'est possible mais pas dans le langage dans lequel j'ai implémenté mon exemple.
Maintenant j'aimerais que tu me montres comment avec une démonstration mathématique on prend en compte le dépassement de pile =D Je suis sérieux car là réside toute la surpuissance du test mathématique par rapport à une implémentation correcte et des tests bien pensés.
Quant au code que tu montres, c'est moi qui ait donné l'implémentation. C'est pas toi déjà qui parlait de malveillance involontaire ? Là le troll involontaire
à quand le braquage de banque involontaire ? :p
Quand on fait du TDD on s'inscrit dans une démarche de qualité. Si tu me livres ce "code" et que j'ai un bug, je tracerai l'appel et je regarderai un peu ce qu'il me livre. Et je trouverai le bug bien avant toi qui aura choisi de te taper *tout* le code source livré, forcément, puisque pour prouver mathématiquement le code livré il te faut bien le lire.
Pour les erreurs vraiment stupide voire le sabotage je ne vois pas vraiment ce que tu veux montrer ... Mais il est vrai que c'est mieux je crois si c'est la même personne qui écrit un test et qui implémente la solution correspondante. Dans le cas du module dict pour erlang, le test s'adresse à un développeur. C'est donc normalement quelqu'un qui choisira la simplicité et qui implémentera un vrai dict plutôt que de hardcoder toutes les solutions du test manuellement. On parle d'un professionnel.
Bref dans mon exemple je fournissais un test en ayant connaissance de l'implémentation, je ne m'engagerai jamais sur du code que je n'ai pas fait (même si c'est moi qui ait écrit le test).
Enfin concernant le post de Ter Rowan, tu ne peux pas remplacer un stagiaire sur 3 ans par un ingénieur sur 3 mois. Ils ne font pas le même boulot. Ce n'est pas qu'une histoire de coûts. Ton ingé en a marre de reprendre du code au bout de deux semaines mais toi tu as besoin d'une personne pendant 3 ans pour faire certains travaux. Tu ne sais pas quels contrats tu aura dans un an, tu ne peux donc pas filer ce boulot à ton ingé. En contrepartie, même si tu as tout le temps nécessaire pour un projet, tu ne vais pas confier de prouver la correctidudition du code à un stagiaire dont ce n'est clairement pas le boulot. Tu peux tout au plus lui demander d'essayer de la prouver et de trouver les erreurs flagrantes mais tu aura besoin d'une compétence au dessus pour avoir confiance en ton code. Donc tu as besoin de l'ingé, et c'est clairement beaucoup plus cher, je suis d'accord avec son post. Des tests bien sentis et un peu de débug comme d'habitude font généralement de très bons résultats quand c'est fait par des bons.
Maintenant j'aimerais que tu me montres comment avec une démonstration mathématique on prend en compte le dépassement de pile =D Je suis sérieux car là réside toute la surpuissance du test mathématique par rapport à une implémentation correcte et des tests bien pensés.
Quant au code que tu montres, c'est moi qui ait donné l'implémentation. C'est pas toi déjà qui parlait de malveillance involontaire ? Là le troll involontaire
à quand le braquage de banque involontaire ? :p Quand on fait du TDD on s'inscrit dans une démarche de qualité. Si tu me livres ce "code" et que j'ai un bug, je tracerai l'appel et je regarderai un peu ce qu'il me livre. Et je trouverai le bug bien avant toi qui aura choisi de te taper *tout* le code source livré, forcément, puisque pour prouver mathématiquement le code livré il te faut bien le lire.
Pour les erreurs vraiment stupide voire le sabotage je ne vois pas vraiment ce que tu veux montrer ... Mais il est vrai que c'est mieux je crois si c'est la même personne qui écrit un test et qui implémente la solution correspondante. Dans le cas du module dict pour erlang, le test s'adresse à un développeur. C'est donc normalement quelqu'un qui choisira la simplicité et qui implémentera un vrai dict plutôt que de hardcoder toutes les solutions du test manuellement. On parle d'un professionnel.
Bref dans mon exemple je fournissais un test en ayant connaissance de l'implémentation, je ne m'engagerai jamais sur du code que je n'ai pas fait (même si c'est moi qui ait écrit le test).
Citation :De plus tu ne réponds que sur les test du code pour le débug, qu'as tu as dire pour le reste, ne penses-tu pas que ce sont déjà des éléments suffisants pour tester le TDD ?
Enfin concernant le post de Ter Rowan, tu ne peux pas remplacer un stagiaire sur 3 ans par un ingénieur sur 3 mois. Ils ne font pas le même boulot. Ce n'est pas qu'une histoire de coûts. Ton ingé en a marre de reprendre du code au bout de deux semaines mais toi tu as besoin d'une personne pendant 3 ans pour faire certains travaux. Tu ne sais pas quels contrats tu aura dans un an, tu ne peux donc pas filer ce boulot à ton ingé. En contrepartie, même si tu as tout le temps nécessaire pour un projet, tu ne vais pas confier de prouver la correctidudition du code à un stagiaire dont ce n'est clairement pas le boulot. Tu peux tout au plus lui demander d'essayer de la prouver et de trouver les erreurs flagrantes mais tu aura besoin d'une compétence au dessus pour avoir confiance en ton code. Donc tu as besoin de l'ingé, et c'est clairement beaucoup plus cher, je suis d'accord avec son post. Des tests bien sentis et un peu de débug comme d'habitude font généralement de très bons résultats quand c'est fait par des bons.