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(...)
Journal Un quart des développeurs ne testent jamais leurs programmes.
14
déc.
2006
# service spécialisé :-)
Posté par CrEv (site web personnel) . Évalué à 10.
Quant au sérieux, c'est 01net... (enfin c'est mon avis...)
[^] # Re: service spécialisé :-)
Posté par gst . Évalué à 4.
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 Gluck_ (site web personnel) . Évalué à 7.
# test unitaires?
Posté par ecyrbe . Évalué à 10.
[^] # Re: test unitaires?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
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 Guillaume Denry (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 8.
[^] # Re: test unitaires?
Posté par パパフラクス . Évalué à 9.
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 (site web personnel) . Évalué à 1.
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.
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 (site web personnel) . Évalué à 3.
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.
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 . Évalué à 2.
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 Pierre Tramonson . Évalué à 3.
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 . Évalué à 4.
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 kiai . Évalué à 4.
# la preuve ?
Posté par Nahuel . Évalué à 1.
# Comme on dit
Posté par farib . Évalué à 10.
[^] # Re: Comme on dit
Posté par Axel R. (site web personnel) . Évalué à 6.
[^] # Re: Comme on dit
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
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 neriki (site web personnel) . Évalué à 3.
[^] # Re: Comme on dit
Posté par Slauncha (site web personnel) . Évalué à 4.
[^] # Re: Comme on dit
Posté par ~ lilliput (site web personnel) . Évalué à 2.
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 Croconux . Évalué à 8.
[^] # Re: Mouais
Posté par farib . Évalué à 6.
Viandez, plutôt, non ?
[^] # Re: Mouais
Posté par bartman . Évalué à 3.
- 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 golum . Évalué à 3.
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 Maillequeule . Évalué à 2.
M
[^] # Re: Mouais
Posté par liberforce (site web personnel) . Évalué à 1.
(vive la ratp !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.