+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Le « Test Driven Development » et son démon de l'induction (/showthread.php?tid=7601)
Le « Test Driven Development » et son démon de l'induction - Sephi-Chan - 26-02-2016
RE: Le « Test Driven Development » et son démon de l'induction - Argorate - 26-02-2016
Je pense en effet qu'il n'a pas comprit l’intérêt. TDD c'est vraiment super intéressant.^^
Citation :Le principe même de l’orienté objet, à savoir l’encapsulation ou « la boite noire », fait qu’on ne peut s’assurer du bon fonctionnement d’une méthode qu’en en lisant le code source, et non en la testant de l’extérieur.Ah bon? Hier encore, j'ai encore écrit des méthodes, je les passe au test, paf j'ai eu 3 ou 4 problèmes à régler avant qu'elle ne marche.
Ton argumentation c'est de dire: puisque vous n'êtes pas exhaustif dans les tests, la preuve mathématique n'est pas faite que votre fonction marche bien tout le temps.
C'est vrai... Sauf que sous entendre que le cerveau humain en lisant cette même méthode testera de manière exhaustive (et même mieux qu'un PC) la dite méthode, c'est vraiment ridicule...
Si tu veux de l’exhaustivité, pour des méthodes simple comme abs(), tu peux tjs faire une boucle dans ton test, comme ça tu testeras de -9999999 à +9999999, c'est tjs pas exhaustif, mais ça devrait couvrir tout tes cas d'utilisation XD
Sinon là je suis en train de continuer mon moteur de combat pour TMI, et bien quand j'ai créer ma méthode hit?() j'ai utilisé l'appel à des méthodes qui n'existait pas encore ! C'est exactement ça l'esprit TDD, c'est pas de définir un cas particulier, c'est d'écrire du code tel que tu voudrais qu'il soit, sans avoir écrit toutes les boites noires qu'il utilise au préalable. On pourrait dire que c'est coder en asynchrone...
Traditionnellement, on écrit du code et dès qu'on a besoin d'une méthode, on va l'écrire, puis on revient à l'endroit qui l'utilise et on continue.
Là, le principe c'est plus de dire : j'écris toute ma méthode, sans partir ailleurs, même si j'appel des trucs qui n'existe pas encore, on s'en fou, on écrit la méthode jusqu'au bout, point. Puis après, on va aller faire les boites noires manquantes (où on réutilisera le même technique par ailleurs).
PS: je trouve rspec tellement illisible en comparaison de mes tests^^ sans doute une question d'habitude :p
RE: Le « Test Driven Development » et son démon de l'induction - Xenos - 26-02-2016
C'est agréable de se savoir lu
J'essaierai d'ajouter un bouton "Réagir sur JeuWeb" en bas des articles, qui renverrait idéalement soit sur l'ouverture d'un nouveau sujet (si l'article n'a pas été débattu), soit sur le sujet de débat existant (s'il y en a un).C'est effectivement un argument intéressant que d'utiliser les tests comme cas d'exemple d'utilisation d'une méthode, à des fins de documentation. Après, une méthode est censée être élémentaire et simple: est-ce que l'ajout de tests pour décrire son intention reflète une méthode trop complexe (faisant trop de choses)? Formulé autrement, c'est le nom de la méthode, ses paramètres et la première ligne de documentation qui devraient indiquer l'intention de la méthode, et le test est une illustration d'exemple?
@Argorate:
Tu peux tester ta boucle: tu vas juste tester les cas que t'avais prévu. Or, à mon sens, ce sont ceux qui n'ont pas été prévus qui foireront.
Ce que tu décris est simplement la séparation entre la signature publique d'une méthode et son implémentation. Je ne vois pas le lien avec le TDD.
Ecrire des tests pour faire office d'exemple de documentation/d'utilisation, je comprends le concept et je il est effectivement intéressant. Mais je reste quand même sceptique quant au principe de se servir de ses tests comme spec...
RE: Le « Test Driven Development » et son démon de l'induction - Akira777 - 27-02-2016
Excellent.
Assez d'accord avec Argorate sur le fond du TDD.
Pour ceux qui ne connaissent pas le TDD et qui découvrent.
En PHP c'est pas mal avec phpspec.
Exemple de petits algos en PHP ici pour ceux qui veulent en savoir plus : https://github.com/laracasts/Code-Katas-in-PHP
Pour ma part, j'essai de plus en plus de faire du TDD, et je commence à avoir du mal à m'en passer....
RE: Le « Test Driven Development » et son démon de l'induction - Argorate - 27-02-2016
Oui, quand on y a gouter, on commence à ne vouloir travailler plus que comme ça ^^
J'avoue que Rails permettant l’accès et l’exécution dans sublim text lui même, même pas besoin de ligne de cmd, un simple raccourci suffit, ça incite bien à tester la méthode.
Citation :Je ne vois pas le lien avec le TDD.oui, c'est bien pour ça que j'ai introduit mon propos en disant que tu n'as pas comprit, c'est pas une "boite", c'est juste que je pense que tu n'as pas encore vu l’intérêt... ça viendra
RE: Le « Test Driven Development » et son démon de l'induction - Sephi-Chan - 27-02-2016
(26-02-2016, 10:07 PM)Xenos a écrit : C'est effectivement un argument intéressant que d'utiliser les tests comme cas d'exemple d'utilisation d'une méthode, à des fins de documentation. Après, une méthode est censée être élémentaire et simple: est-ce que l'ajout de tests pour décrire son intention reflète une méthode trop complexe (faisant trop de choses)? Formulé autrement, c'est le nom de la méthode, ses paramètres et la première ligne de documentation qui devraient indiquer l'intention de la méthode, et le test est une illustration d'exemple?
Comme tu le vois, dans la vraie vie les méthodes sont moins élémentaires. Elles ne sont pas souvent pures et ne font pas que retourner une valeur : elles modifient la base de données. En émettant des attentes sur l'état de la base de données après le passage du code dans certaines conditions de départ, tu définis un contrat dans ton code, et tu n'implémentes que le minimum pour t'y conformer. Bien sûr, ce n'est qu'un contrat qui communique une intention : il requiert donc un peu de bon sens pour ne pas coder le cas de réussite du test en dur, mais je suppose que tu l'avais compris.
(26-02-2016, 10:07 PM)Xenos a écrit : @Argorate:
Tu peux tester ta boucle: tu vas juste tester les cas que t'avais prévu. Or, à mon sens, ce sont ceux qui n'ont pas été prévus qui foireront.
Ce que tu décris est simplement la séparation entre la signature publique d'une méthode et son implémentation. Je ne vois pas le lien avec le TDD.
La boucle dans le test est une très mauvaise idée : ça ne sert strictement à rien d'autre qu'en ralentir l'exécution.
Ce qu'il décrit, c'est simplement le fait de réfléchir à la tronche du code que tu appelles, et ce avant de l'écrire. C'est ce que tout le monde fait mentalement, TDD ne fait que formaliser ça.
(26-02-2016, 10:07 PM)Xenos a écrit : Ecrire des tests pour faire office d'exemple de documentation/d'utilisation, je comprends le concept et je il est effectivement intéressant. Mais je reste quand même sceptique quant au principe de se servir de ses tests comme spec...
Pourquoi sceptique ? Quels défauts y vois-tu ?
Ne serait-ce que pour la rapidité de développement, ça vaut le coup ! C'est paradoxal venant d'un type qui ne sort jamais rien. Rester concentré à concevoir et développer le système, sans s'embêter à lancer du code à la main, se remettre dans les conditions de départ, etc. Je mets mon éditeur en split view (le test d'un côté, le code de l'autre) et je lance juste le test sur lequel je bosse (Command + Shift + R), quand il passe je lance le fichier de test entier (pour éviter les régressions, Command + Shift + T).