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

Posté par  .
Étiquettes : aucune
0
14
déc.
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(...)
  • # service spécialisé :-)

    Posté par  (site web personnel) . Évalué à 10.

    Je test pas, je donne mes programmes au service test & qualité, faut bien justifier leur présence ;-)

    Quant au sérieux, c'est 01net... (enfin c'est mon avis...)
    • [^] # Re: service spécialisé :-)

      Posté par  . Évalué à 4.

      << Source : étude de l'Ireq pour le compte de l'Opiiec. >>

      Mais bon, 1/4, c'est déjà pas mal - 'fin, ca veut dire qu'on a encore moyen de faire mieux.. ouaaaéééé...

      Et puis il y a le bon test le mauvais test et le test brute.
    • [^] # Re: service spécialisé :-)

      Posté par  (site web personnel) . Évalué à 7.

      faut déjà voir ce qu'on entend par tester. On peut tester que ça marche correctement (et je vais rarement plus loin que ça quand je développe pour moi) et tester de manière systématique qu'il n'y ait pas de bug.
  • # test unitaires?

    Posté par  . Évalué à 10.

    si "tester" signifie faire des tests unitaires, je veux bien croire le sondage...
    • [^] # Re: test unitaires?

      Posté par  (site web personnel, Mastodon) . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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...
      • [^] # Re: test unitaires?

        Posté par  . É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  . É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.
    • [^] # Re: test unitaires?

      Posté par  . Évalué à 4.

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

    Posté par  . Évalué à 1.

  • # Comme on dit

    Posté par  . Évalué à 10.

    C'est pas leur boulot, mais celui des utilisateurs, non ?
    • [^] # Re: Comme on dit

      Posté par  (site web personnel) . Évalué à 6.

      et j'imagine que tu mets tes programmes en GPL pour éviter d'avoir à les déboguer toi même ?
      • [^] # Re: Comme on dit

        Posté par  (site web personnel) . Évalué à 10.

        Hey pas mal comme idée.
        Je vais lancer un tas de projets dans lesquels je n'écrirais que le int main(int argc, char *argv[]) {} et les programmeurs de la communauté rempliront les trous pour moi.
        Je vais me faire des couilles en or !
        • [^] # Re: Comme on dit

          Posté par  (site web personnel) . Évalué à 3.

          Pense aussi à faire des beaux logos qui tu pourras coller sur des mugs et des tshirts. :D
        • [^] # Re: Comme on dit

          Posté par  (site web personnel) . Évalué à 4.

          Dépose vite ton brevet .... sur ton nouveau concept/idée : "Codage par le vide", encore "Implémentation par le vide".
        • [^] # Re: Comme on dit

          Posté par  (site web personnel) . Évalué à 2.

          Comme quoi personne ne fait de test ...

          Bon mon premier patch :

          int main(int argc, char *argv[]) { return 0; }

          http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk

  • # Mouais

    Posté par  . Évalué à 8.

    Je dois dire que la partie consacrée à l'opinion que les développeurs ont de leur situation m'a plutot surpris. En gros tout le monde est super content, tout va bien, c'est le bonheur. C'est curieux mais ce n'est pas vraiement l"écho que j'entends, surtout chez ceux qui sont en SSII (aka "marchands de viande"). Je comprends tout à fait la réaction du Munci. D'autant que dès la première page on peut lire "membre du Syntec". Là je comprends mieux. Les méthodes dignes du XIXe siècle des sociétés du secteur commencent à être connues et le Syntec a probablement senti qu'il était temps qu'une petite étude "indépendante" viennent redorer leur image. Mais, non, mais, non. On n'est pas des négriers, viendez chez nous.
    • [^] # Re: Mouais

      Posté par  . Évalué à 6.

      >On n'est pas des négriers, viendez chez nous.

      Viandez, plutôt, non ?
    • [^] # Re: Mouais

      Posté par  . Évalué à 3.

      tu cerne bien le sujet, et comment les SSII existerait si on ne faisait pas appel à leur services ?. Ce sont les sociétés (ou groupes maintenant) qui utilsent ces "ressources partageables" (nous en l'occurence) et peuvent ainsi se permmettre de stopper un projet (parfois massif) sans avoir à :

      - faire appel à un DRH
      - parlementer avec des syndicats
      - avoir une masse salariale surchargée ( un préstataire n'est pas gratuit non plus)
      - supporter une grève (c'est tout gentil un préstataire, ça fait pas de bruit)
      - et surtout se faire une mauvaise publicité auprès de ses actionnaires, politques (pour les aides), et clients

      Pratique non ?

      Mais ne crachons pas non plus sur les SSII, parfois il y en à qui ont un côté humain et qui permettent d'avoir le boulot que l'on souhaite pas celui que l'on à intérêt à garder en alimentaire.
      D'autant plus que les sociétés actuelles s'appuient de plus en plus sur un beau model féodal.

      Je vous renvoie au livre "principe de Peter " et en ce moment Marianne (on aime ou pas) décrit bien cela.
      • [^] # Re: Mouais

        Posté par  . Évalué à 3.

        Oui en fait les 2 sont complémentaires.

        Les SSII poussent à l'infogérance et à l'outsourcing pour récupérer des marchés et les DSI les mettent en concurrence pour baisser les coûts.

        Mais bon c'est quand même bien le Syntec qui faisait du lobbying pour le contrat de projet afin d'avoir des esclaves jetables à volonté qui se retrouvent à la charge du contribuable en inter-projet.
        On ne parlera pas des SSII qui font leur business avec l'offshore et autre nearshore.
        Faut dire que la directive Bolkenstein qui est maintenant passée n'a pas tenu toutes ses promesses sur le principe d'origine donc ca les embêtent un peu de payer leurs untermenschen au tarif local.
    • [^] # Re: Mouais

      Posté par  . Évalué à 2.

      En même temps ... OUI, il y a des gens en SSII qui sont heureux, si si.

      M

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.