Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Journal : Un quart des développeurs ne testent jamais leurs programmes.

Posté par zeanmi () le 14 décembre 2006
Je ne sais pas si c'est vraiment très sérieux [1], ça me paraît un peu gros, pas vous ? D'autant que dans l'étude [2], la seul phrase plus ou moins en rapport est "Et lorsqu’ils réalisent des tests, ils ont le plus souvent recours à des outils internes (65%)."

[1] http://www.01net.com/article/336085.html
[2] http://www.f3c-cfdt.fr/actualites/informaticien-et-heureux/a(...)

> Lire le journal (29 commentaires, moyenne: 5,1).  

Vous avez demandé le commentaire #784839.

test unitaires?

Posté par Bench () le 14/12/2006 à 22:24. (lien). Évalué à 10.

si "tester" signifie faire des tests unitaires, je veux bien croire le sondage...

  • [^]Re: test unitaires?

    Posté par Laurent J (page perso, ) le 15/12/2006 à 09:11. (lien). Évalué à 9.

    euh.. si "tester" signifie faire des tests unitaires, c'est pas un quart des développeurs, mais au moins trois quarts des développeurs qui ne font pas de tests.

    Je ne vois pas beaucoup de projets qui ont des tests unitaires.. (et en SSII, quasiement aucun, pas le temps...)

    • [^]Re: test unitaires?

      Posté par Guid (page perso, ) le 15/12/2006 à 09:15. (lien). Évalué à 5.

      Je ne vois pas beaucoup de projets qui ont des tests unitaires.. (et en SSII, quasiement aucun, pas le temps...)


      Le but des TU, c'est justement de te faire gagner du temps :-)
      Enfin bon, j'imagine qu'en SSII, c'est mieux quand le code est moins perenne.... si vous voyez ce que je veux dire ;)

      • [^]Re: test unitaires?

        Posté par Olivier Serve (Jabber id, page perso, ) le 15/12/2006 à 09:26. (lien). Évalué à 8.

        Avec des TU, on gagne du temps à moyen et long terme. Pas évident à justifier dans un secteur qui tourne à court terme.

        • [^]Re: test unitaires?

          Posté par Papa Furax (page perso, ) le 15/12/2006 à 10:08. (lien). Évalué à 9.

          Je confirme.
          Et quand tu arrive sur des projets à long terme, réalisés par des
          prestataires dont les mission n'exèdent pas quelques mois, c'est le ponpon:
          Modifier un libellé peut facilement prendre une demi journée, le temps de retrouvé le code dans les centaines de milliers de ligne amassée au fil du temps. Comme rien n'est testé, il faut faire super gaffe à ce que tu touches, et impossible de faire le moindre refactoring: trop peur de casser. Donc plus ça va ,et pire c'est.
          Le bonheur quoi!

          • [^]Re: test unitaires?

            Posté par Sylvain Rampacek (Jabber id, page perso, ) le 15/12/2006 à 10:50. (lien). Évalué à 1.

            et impossible de faire le moindre refactoring: trop peur de casser.

            heu...
            je ne vois pas ce qui risque d'être cassé si ton outil de refactoring fonctionne correctement !

            après, il faut toujours avoir la possibilité de revenir en arrière (sauvegarde et/ou fonction proposé par l'outil)

            • [^]Re: test unitaires?

              Posté par Papa Furax (page perso, ) le 15/12/2006 à 11:10. (lien). Évalué à 5.

              je ne vois pas ce qui risque d'être cassé si ton outil de refactoring fonctionne correctement !

              En fait je prends refactoring au sens large. Ca comprends donc tout ce qui est gérable par un outils de refactoring mais aussi, la suppression de code mort (est-il bien mort d'ailleurs), la réecriture de code pourave
              , changement de structures de données inefficaces, réécriture de requêtes, etc.

              Et souvent, sur des projets avec test unitaire, j'ai choppé des différences de comportement, minimes, mais en fait pas tant que ça: par exemple une methode renvoit une liste vide, alors qu'un null est attendu dans certains cas. Ou alors lève une exception sur un parametre qui ne devrait pas être accépté, ms qui passait, par hasard dans l'implémentation précedende.

              Au passage j'ajoute que bien souvent, on choisit les outils pour toi, et tu n'a pas forcément des choses aussi puissante que eclipse,

              après, il faut toujours avoir la possibilité de revenir en arrière (sauvegarde et/ou fonction proposé par l'outil)
              On est d'accord. Mais il te faut un retour pour savoir si tu retournes ou non en arrière: le premier retour c'est les tests unitaires.

              De plus, une fois le code livré, le "undo" c'est plus compliqué.
              Dans le meilleurs des cas la validation chope le bug, et ça fait un bug interne. Tu reviens à la version qui marche.

              Mais souvent: la validation n'est pas efficace, et bien souvent les tests sont réalisés à la main, et donc il est très rare que l'equipe de validation refasse des tests sur des choses déjà testés et qui marchaient avant.

              • [^]Re: test unitaires?

                Posté par Sylvain Rampacek (Jabber id, page perso, ) le 15/12/2006 à 12:15. (lien). Évalué à 3.

                ok, donc je comprend mieux ce que tu as voulu dire...

                pour la "réécriture de code pourave" et la "suppression de code mort", oui, il faut faire très attention à tous les cas !

                mais le simple renommage de libéllé, ça va ! (c'était ton exemple de départ), un outil de refactoring le fera sans problème.

                après, pour le changement de niveau classe héritière/classe mère, ou autre modification, oui, cela peut induire des effets de bord...

                • [^]Re: test unitaires?

                  Posté par Papa Furax (page perso, ) le 15/12/2006 à 12:46. (lien). Évalué à 4.

                  mais le simple renommage de libéllé, ça va ! (c'était ton exemple de départ), un outil de refactoring le fera sans problème

                  En fait non, car c'est une String, pas besoin de refactoring pour ça.
                  En ce que je tentais d'expliquer c'est que "pas de test unitaire"
                  -> "pas de refactoring" -> "croissance anarchique du code"

                  Dans le cas de mon petit libellé, le plus dur c'est de trouver ou il se cache, dans un monceau de page nommées n'importe comment, et pour ça d'être obligé de suivre du code inutilement compliqué.

                  Sinon, les tests unitaire, j'ai pratiqué, alliés à d'autres idées venant de XP (intégration continue, travail à deux, etc.), et oui, indéniablement, ça fait gagner du temps, et de la *qualité*

                [^]Re: test unitaires?

                Posté par imalip (page perso, ) le 15/12/2006 à 13:23. (lien). Évalué à 2.

                C'est marrant, tout ca me fait penser au code source d'une certaine équipe de formule 1...

                S'il y a bien une chose que j'ai apprise, c'est que faire du code propre n'est pas une nécessité pour gagner 6 championnats du Monde consécutifs. En fait, on se demande meme comment la voiture réussit a bouger...

                --
                "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

      [^]Re: test unitaires?

      Posté par Pierre Tramonson () le 15/12/2006 à 10:45. (lien). Évalué à 3.

      Ne dis pas n'importe quoi sur les TU dans les SSII.
      Moi j'en fait faire, et je constate autour de moi que c'est une pratique répandue. C'est plutôt nos clients qui pour rogner sur le prix, veulent diminuer les charges de suivi de projet et de tests/assistance recette.
      Ca donne un beau prototype, ça, pas un beau projet !

      Alors après peut-être que les tests ne sont pas exhaustifs (c'est en général le cas) et que ça donne l'impression d'être baclé, mais il est faux de dire qu'aucun TU n'est réalisé.

      Surtout pour les projets Java/DotNet, on dispose quand même de frameworks de tests bien utiles, qui permettent de faire des tests automatiquement sans passer trop de temps à développer les cas de tests.

      • [^]Re: test unitaires?

        Posté par Dring FirebirdVsMySql () le 15/12/2006 à 12:23. (lien). Évalué à 4.

        On vit manifestement pas dans le même monde. Je préfère de loin le tien, cela étant.

        Autour de moi, je vois plein de programmes écrits dans des langages différents. Ca donne ça :

        1) Les softs en Cobol sur Mainframe/Mini. J'ai jamais vu la queue d'un test unitaire.

        2) Les softs en client lourd, avec le fonctionnel dans la partie base de données. J'ai déjà vu des tests unitaires, mais ils étaient pourris ou inutiles.

        3) Les softs en client léger (J2EE / .Net). Là, y de tout, du taux de couverture 100%, avec lancement automatique par Maven, etc, au "c'est quoi un test unitaire".

        Comme les softs en client léger représentent moins de 25% de notre parc de développement, les statistiques me paraîssent plutôt correctes.

        --
        Non, rien.

    [^]Re: test unitaires?

    Posté par kiai () le 15/12/2006 à 09:11. (lien). Évalué à 4.

    Et si tester inclu les tests en charge je pense que c'est même bien pire que dans ce sondage...