IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

Les bonnes habitudes du développement piloté par les tests


Sujet :

ALM

  1. #21
    Membre éprouvé
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    307
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 307
    Points : 983
    Points
    983
    Par défaut
    Citation Envoyé par Cyrilange Voir le message
    Grosse perte de temps. Je n'ai jamais et je ne ferais jamais ce genre de chose.
    Tout le contraire pour moi. Gros gain de temps, je code les tests d'abord puis la fonctionnalité buggée à l'arrache pour que ca compile et que ca casse. Ensuite je code la fonction jusqu'à ce que le(s) test(s) passent. Je gagne du temps à trouver les bugs (du temps perdu avec le debuger pour des bugs à la con) et je pense avoir un code moins buggé avec ça (les bugs chez les clients c'est toujours le pire : cout en terme d'image, difficulté à reproduire, se faire expliquer...). Ca permet aussi de donner un bon rythme (test, dev, refactor). En bonus, j'ai un code testé que je peux faire évoluer sans trop casser.

  2. #22
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par renoo Voir le message
    je code les tests d'abord puis la fonctionnalité buggée à l'arrache pour que ca compile et que ca casse.
    Malheureux, c'est du pain bénit pour les détracteurs de TDD qui vont dire que tu perds du temps à imaginer ton implémentation à l'arrache pour ensuite l'effacer

    Plus sérieusement, je préfère créer juste une méthode vide ou qui throw une NotImplementedException (souvent générée automatiquement par une fonctionnalité de refactoring dans l'IDE), ça suffit pour faire planter le test.

  3. #23
    Membre éprouvé
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    307
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 307
    Points : 983
    Points
    983
    Par défaut
    Citation Envoyé par Luckyluke34 Voir le message
    Plus sérieusement, je préfère créer juste une méthode vide ou qui throw une NotImplementedException (souvent générée automatiquement par une fonctionnalité de refactoring dans l'IDE), ça suffit pour faire planter le test.
    Oui c'est bien mieux comme ça et c'est plus ça que je fais d'ailleurs : une fonction qui a le bon profile mais la plus courte possible et buggée (return 1; si ca retourne un int) et c'est vraiment le plus rapide à coder. Le truc c'est que cette étape permet aussi tester un peu le test.

    Mais sinon écrire une première implémentation pas top sur certains aspects (pex perf & co) et y revenir ensuite avec un ensemble de tests dont une partie peut être conservée... ça me semble plutôt du temps gagné, d'autant plus que peut être il n'y aura pas à revenir dessus (premature optimization is the root of all evil).

  4. #24
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2013
    Messages : 485
    Points : 2 149
    Points
    2 149
    Par défaut
    Pour ceux qui se pose des questions sur l’intérêt du TDD, je vous invite à lire les articles de Bruno (http://bruno-orsier.developpez.com/)
    Il propose un tutoriel de TDD simple (http://bruno-orsier.developpez.com/t...inos/index.php) bien guider par les recommandations d'Uncle Bob.
    Même s'il commence à dater de quelques années, il est toujours d'actualité.
    Il propose aussi des réflexions intéressante sur le refactoring et les tests en isolation.
    Ses articles parles de .NET, mais il est assez facile de les extrapoler dans d'autres langages.

    Je vais reprendre le questionnement de certain: a quoi ça sert? Est-ce que cela fait gagner du temps?
    J'ai travaillé, il y a quelque temps, sur un petit projet open-source d'un client dure en Java (300 classe, 12000 lignes): connexion à un serveur en http et affichage d'interface swing.
    J'avais eu la bonne idée de réaliser ce client initial en TDD avec une jolie collection de tests en isolation sur les différentes couches.
    Ce choix initial, je l'avais fait pour m'assurer non seulement d'avoir un code au plus simple de ce que je voulais faire mais également d'avoir pour l'avenir un ensemble de tests "garde-fou" me permettant de réaliser des évolutions future.
    Dernièrement, j'ai été amener à le convertir en Ajax/JQuery.
    Et bien j'ai juste commencé à convertir mes tests TDD du java vers le jquery.
    Ensuite, je n'ai qu’a eut à implémenter chacun des objets et fonctions qui faisait "planter" mes tests.
    Je fais la conversion en 2 semaines environs.
    C'est sur les parties "esthétique" du projet (css) que j'ai passé plus de temps: les parties qui n'était pas couvert par le TDD finalement.
    L'outil Ajax est déployé et assez peut de retour et de bug.
    Je n'aurais pas eu cette batterie de tests qui m'ont guider sur les fonctionnalités à avoir pour être compatible, je ne pense pas que je me serais lancer dans cette migration ... ou alors j'y serais toujours.

    Donc, non, le TDD est loin de faire perdre du temps.
    On en gagne un peu au développement.
    On en gagne encore plus lors d'un changement de technologie.
    De plus, la qualité de ce que l'on obtiens est meilleur en allant droit à l'essentiel.

    N'oubliez pas qu'un développement ne se termine pas à la première livraison.
    Le plus souvent, il y a des améliorations, des corrections, des évolutions de votre logiciel.
    Et d'avoir déjà des bloques logiciels bien refactorisés et "protégés" par des tests d'anti-regression est un confort pour le future.

Discussions similaires

  1. [PHPUnit] Développement piloté par les tests
    Par Invité dans le forum Bibliothèques et frameworks
    Réponses: 2
    Dernier message: 12/11/2013, 13h19
  2. Réponses: 9
    Dernier message: 26/01/2012, 10h33
  3. développement piloté par les tests pour un jeu vidéo
    Par Mindiell dans le forum Méthodes Agiles
    Réponses: 1
    Dernier message: 06/08/2009, 10h28
  4. Développement piloté par les tests avec PHPUnit
    Par Invité dans le forum Bibliothèques et frameworks
    Réponses: 0
    Dernier message: 18/11/2008, 19h53

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo