Mais ça arrive. Je l'ai vécu et ce n'est pas du suicide.
C'est peut-etre pas du suicide mais c'est une grosse connerie inefficace.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
Alors c'est quoi la solution ? Ne rien tester car on ne peut pas tout tester ? Tu crois qu'ils font ca de cette maniere sur les systemes critiques d'Ariane et autres ?
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Niveau grosses applis je crois que chez MS on connait, et les tests unitaires sont la.
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
Moi je te donnes deja la reponse :
a) Ca prend du temps
b) C'est bcp plus efficace qu'avoir un gars qui audite le code, auditer le code ne te donne pas la possibilite de resoudre les scenarios bases sur du multithreading pousse par exemple ou sur des cas de ressources limitees, car souvent trop complexe a analyser par un etre humain
c) Un audit de code ne te permet pas de confirmer que ton code fonctionne comme prevu, seul un test du code en question le permet
Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ben tant mieux, c'est pour ca que le test a ete cree. Si les formats ont ete changes volontairement, il faut alors modifier le test.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
Mon petit doigt me dit que ta vraie vie ne correspond pas du tout a la mienne, ni a celle de mes 25'000 collegues ici ni a celle de Philippe. C'est de cette maniere que les plus gros softs de la planete(y compris non-MS) sont developpes, et il y a une raison pour cela : c'est plus efficace.
[^] # Re: ???
Posté par pasBill pasGates . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 5.
C'est peut-etre pas du suicide mais c'est une grosse connerie inefficace.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
Alors c'est quoi la solution ? Ne rien tester car on ne peut pas tout tester ? Tu crois qu'ils font ca de cette maniere sur les systemes critiques d'Ariane et autres ?
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Niveau grosses applis je crois que chez MS on connait, et les tests unitaires sont la.
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
Moi je te donnes deja la reponse :
a) Ca prend du temps
b) C'est bcp plus efficace qu'avoir un gars qui audite le code, auditer le code ne te donne pas la possibilite de resoudre les scenarios bases sur du multithreading pousse par exemple ou sur des cas de ressources limitees, car souvent trop complexe a analyser par un etre humain
c) Un audit de code ne te permet pas de confirmer que ton code fonctionne comme prevu, seul un test du code en question le permet
Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ben tant mieux, c'est pour ca que le test a ete cree. Si les formats ont ete changes volontairement, il faut alors modifier le test.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
Mon petit doigt me dit que ta vraie vie ne correspond pas du tout a la mienne, ni a celle de mes 25'000 collegues ici ni a celle de Philippe. C'est de cette maniere que les plus gros softs de la planete(y compris non-MS) sont developpes, et il y a une raison pour cela : c'est plus efficace.