27-02-2016, 11:41 AM
(Modification du message : 27-02-2016, 11:42 AM par Sephi-Chan.)
(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).