> 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
Je doute que tu arrives a gerer tes 300 parametres et tes 200 autres avec une seule fonction. Tu as forcement un decoupage du travail qui t'oblige a separer les taches. Une fois que tu as isole les taches, tu peux les tester individuellement.
> Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
En general c'est mieux d'avoir un simulateur sous la main, pour reproduire les cas pourris. J'en ai rarement vu dans le libre malheureusement.
> Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des
> appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ? Ou bien que je vais me dire "la vache, si ca vaut aussi cher, vaut mieux ne pas tester" ? Ton appareil, il a des entrees/sorties qui sont specifiees. Ben tu les utilises pour tes tests.
Tout ce qui a une api peut avoir un test.
> Mais je ne me vois pas demander au boss d'avoir 6 mois de plus
> pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Affabulation. Faire des tests unitaire te fait gagner du temps. Pas le jour ou tu les ecris, mais 6 mois plus tard, quand tu dois modifier le code que tu as ecrit. Tu es bien content de ne pas faire un audit complet de ton code pour verifier que le bug X n'a pas pete ton produit. Tu fais retourner ta suite de test, et hop, tu es tranquil. Les endroits ou ton produit est pete sont clairement isole.
Les tests unitaires, c'est une machine a gagner du temps. Je suis d'accord que c'est contre-intuitif comme idee, mais c'est vraiment le cas dans la pratique.
> Il faut alors que les éléments critiques soient simples.
C'est en effet la caracteristique d'une conception robuste.
> Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
Ah, tu vois qu'on se comprend finalement.
> "Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je ne suis pas d'accord. Pour tout projet de plus d'une heure, les tests unitaires te feront gagner du temps. Pour un projet typique, on code 80% du projet en 20% du temps. Les 20% restants sont les plus durs: bugs d'integration, ajustement de la conception, ...
Avec des tests unitaires, t'as plutot une progression lineaire de facteur 1: 20% du temps, 20% du projet. 50% du temps, 50% du projet. Evidemment, vous ne regardez que les 20 premiers % en disant "putain, je pourrai deja en etre a 80% et je n'en suis qu'a 20%". Mais au final, les dernier % sont torches a vitesse grand V. Tu peux meme te permettre de faire des changements majeurs dans le projet dans la phase finale pour integrer la derniere idee du mec marketing, sans avoir peur de miner ton produit. Alors qu'en general, les devs ne veulent plus toucher a rien dans la phase finale, parce qu'ils ont eu trop de bugs d'integration.
> - Faire un (ou des) test unitaire complet pour gecko
Comme je l'ai deja dit, les developpeurs de gecko font deja leurs tests. Ils ont plein de bouts de code qu'ils utilisent pendant leur dev. Seulement des qu'ils estiment que ca marche, au lieu d'integrer ces bouts de code dans une suite de non-regression, ils jettent.
C'est la qu'on perd du temps. Des choses qui sont developpees mais pas integree au produit. C'est sur que rajouter les tests apres, c'est tres difficile et tres couteux.
> Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Beaucoup moins que pour corriger les bugs de non- regression, pour relire le code et se prendre la tete a essayer de comprendre pourquoi la foncttion X est comme ca sans avoir le test qui explique et qui valide son comportement.
Il est evident cependant que les tests evoluent avec le soft. Mais c'est une bonne chose.
> 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 m'interroge en terme de certitude.
- un developpeur qui audite le code: "je pense que ca marche"
- un test unitaire qui valide le code: "je suis sur que ca marche".
Il n'y a pas photo, je prend la 2e option.
> Mais parfois un module développé n'est utilisé que bien des mois après. [...] 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.
Non ? Tu m'apprend quelque chose, je croyais que tout marchait tout seul et que les tests ne servait qu'a valider la perfection du code que ton cerveau surpuissant avait deja garanti de toute facon.
Mais bien sur que ca arrive ! Et bien tu fais evoluer tes tests, en meme temps que ton module. Un principe de codage fondamental de XP, c'est "on ne code qqch qu'une seule fois". Si ton format change, tu modifies la fonction de lecture du format et le test correspondant. Hop. Si ta representaiton interne doit changer aussi, ben pareil, tu modifies les deux. Une fois que tu as fait ca, tu verifies que tous les modules affectes indirectement par tes changements fonctionnent encore. Tu fais un audit rapide de ta couverture de test sur ces modules. Si elle est bonne, voila, tu t'es economise quelques jours de prise de tete d'audit de tous les modules qui utilisaient ton code.
> Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
Bien sur, ca arrive tous les jours. Mais les tests ne sont pas graves dans la pierre, ils evoluent en meme temps que ton programme te que tes specs.
> Toi t'es dans le rève ou il n'y a pas d'erreurs de conception,
Pas du tout. Je passe meme une grande partie de mon temps a corriger mes erreurs de conception en faisant evoluer mes tests. Le fait d'etre un mauvais concepteur ne me gene pas, car j'ai de bonnes suites de tests.
> il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les
> spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Si c'etait ca, je n'aurai pas besoin d'ecrire des tests. Au contraire, les tests m'aident a gerer tous les problemes classiques d'un projet de facon beaucoup plus zen:
- spec qui evolue => je fais evoluer mes tests
- module non encore dispo => je fais des tests et un simulateur pour le remplacer
- bug a la con decouvert => je fais un test pour encadrer le bug et je cherche tous ses cousins possibles, puis je corrige
- probleme d 'integration dans un autre module, on ne sait pas d'ou vient le probleme => je montre mes suites de test a l'autre developpeur, qui est ensuite convaincu que le probleme vient de son cote
- procedure ISO a suivre pour la validation des specs => j'associe a chaque fonctionnalite un test et mon rapport de test devient ma doc de validation
- je trouve un module super difficile a developper et a tester => c'est un signe de mauvaise conception, je le decoupe jusqu'a pouvoir le tester facilement
- on me dit que a la convergence de trois conditions tres tres rares, le soft ne marche pas => je modifie mon simulateur (pratique de l'avoir developpe avant) pour inclure ces conditions tres tres rares.
etc etc.
Les tests unitaires, c'est vraiment une methodologie de developpement qui me permet d'etre super zen dans ce que je fais et de gerer tous les problemes quotidiens avec du recul.
> Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Mon cauchemard, c'est les developpeurs qui pensent que leur cerveau demesure ne pond que du code correct.
Perso, je suis modeste et pessimiste. Je pense que le code que j'ecris ne marche pas. Alors, je cherche des preuves.
> Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
> J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
Ca rejoint ce que je disais sur la valeur des tests. Ca sert plus qu'au developpeur.
> Retard : 15 jours.
Chapeau!
> Le client ne s'est jamais plaint d'un bug.
C'est la caracteristique d'un programme avec de bons tests unitaires. Tres peu de bugs.
> Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Je pense que tu as pris des risques sur ton projet, que tu mesurais de facon consciente. Il aurait pu t'arriver des problemes, genre le client reviens au bout de 4 mois : "donnez nous ce que vous avez fait , et on arrete le projet. Puisque ca fait 4 mois que vous avez commence, vous en etes a la moitie. On paiera que pour ce qui marche uniquement".
Mais je ne critique pas ta demarche. C'est bien que tu aies reussie a faire ce qui paraissait impossible.
[^] # Re: ???
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
> tu dépends d'un automate qui t'envois 200 autres paramètres,etc
Je doute que tu arrives a gerer tes 300 parametres et tes 200 autres avec une seule fonction. Tu as forcement un decoupage du travail qui t'oblige a separer les taches. Une fois que tu as isole les taches, tu peux les tester individuellement.
> Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
En general c'est mieux d'avoir un simulateur sous la main, pour reproduire les cas pourris. J'en ai rarement vu dans le libre malheureusement.
> Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des
> appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Parce que ca vaut plusieurs millions d'euro, tu crois qu'on ne peut pas faire de test ? Ou bien que je vais me dire "la vache, si ca vaut aussi cher, vaut mieux ne pas tester" ? Ton appareil, il a des entrees/sorties qui sont specifiees. Ben tu les utilises pour tes tests.
Tout ce qui a une api peut avoir un test.
> Mais je ne me vois pas demander au boss d'avoir 6 mois de plus
> pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Affabulation. Faire des tests unitaire te fait gagner du temps. Pas le jour ou tu les ecris, mais 6 mois plus tard, quand tu dois modifier le code que tu as ecrit. Tu es bien content de ne pas faire un audit complet de ton code pour verifier que le bug X n'a pas pete ton produit. Tu fais retourner ta suite de test, et hop, tu es tranquil. Les endroits ou ton produit est pete sont clairement isole.
Les tests unitaires, c'est une machine a gagner du temps. Je suis d'accord que c'est contre-intuitif comme idee, mais c'est vraiment le cas dans la pratique.
> Il faut alors que les éléments critiques soient simples.
C'est en effet la caracteristique d'une conception robuste.
> Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
Ah, tu vois qu'on se comprend finalement.
> "Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je ne suis pas d'accord. Pour tout projet de plus d'une heure, les tests unitaires te feront gagner du temps. Pour un projet typique, on code 80% du projet en 20% du temps. Les 20% restants sont les plus durs: bugs d'integration, ajustement de la conception, ...
Avec des tests unitaires, t'as plutot une progression lineaire de facteur 1: 20% du temps, 20% du projet. 50% du temps, 50% du projet. Evidemment, vous ne regardez que les 20 premiers % en disant "putain, je pourrai deja en etre a 80% et je n'en suis qu'a 20%". Mais au final, les dernier % sont torches a vitesse grand V. Tu peux meme te permettre de faire des changements majeurs dans le projet dans la phase finale pour integrer la derniere idee du mec marketing, sans avoir peur de miner ton produit. Alors qu'en general, les devs ne veulent plus toucher a rien dans la phase finale, parce qu'ils ont eu trop de bugs d'integration.
> - Faire un (ou des) test unitaire complet pour gecko
Comme je l'ai deja dit, les developpeurs de gecko font deja leurs tests. Ils ont plein de bouts de code qu'ils utilisent pendant leur dev. Seulement des qu'ils estiment que ca marche, au lieu d'integrer ces bouts de code dans une suite de non-regression, ils jettent.
C'est la qu'on perd du temps. Des choses qui sont developpees mais pas integree au produit. C'est sur que rajouter les tests apres, c'est tres difficile et tres couteux.
> Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Beaucoup moins que pour corriger les bugs de non- regression, pour relire le code et se prendre la tete a essayer de comprendre pourquoi la foncttion X est comme ca sans avoir le test qui explique et qui valide son comportement.
Il est evident cependant que les tests evoluent avec le soft. Mais c'est une bonne chose.
> 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 m'interroge en terme de certitude.
- un developpeur qui audite le code: "je pense que ca marche"
- un test unitaire qui valide le code: "je suis sur que ca marche".
Il n'y a pas photo, je prend la 2e option.
> Mais parfois un module développé n'est utilisé que bien des mois après. [...] 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.
Non ? Tu m'apprend quelque chose, je croyais que tout marchait tout seul et que les tests ne servait qu'a valider la perfection du code que ton cerveau surpuissant avait deja garanti de toute facon.
Mais bien sur que ca arrive ! Et bien tu fais evoluer tes tests, en meme temps que ton module. Un principe de codage fondamental de XP, c'est "on ne code qqch qu'une seule fois". Si ton format change, tu modifies la fonction de lecture du format et le test correspondant. Hop. Si ta representaiton interne doit changer aussi, ben pareil, tu modifies les deux. Une fois que tu as fait ca, tu verifies que tous les modules affectes indirectement par tes changements fonctionnent encore. Tu fais un audit rapide de ta couverture de test sur ces modules. Si elle est bonne, voila, tu t'es economise quelques jours de prise de tete d'audit de tous les modules qui utilisaient ton code.
> Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
Bien sur, ca arrive tous les jours. Mais les tests ne sont pas graves dans la pierre, ils evoluent en meme temps que ton programme te que tes specs.
> Toi t'es dans le rève ou il n'y a pas d'erreurs de conception,
Pas du tout. Je passe meme une grande partie de mon temps a corriger mes erreurs de conception en faisant evoluer mes tests. Le fait d'etre un mauvais concepteur ne me gene pas, car j'ai de bonnes suites de tests.
> il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les
> spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Si c'etait ca, je n'aurai pas besoin d'ecrire des tests. Au contraire, les tests m'aident a gerer tous les problemes classiques d'un projet de facon beaucoup plus zen:
- spec qui evolue => je fais evoluer mes tests
- module non encore dispo => je fais des tests et un simulateur pour le remplacer
- bug a la con decouvert => je fais un test pour encadrer le bug et je cherche tous ses cousins possibles, puis je corrige
- probleme d 'integration dans un autre module, on ne sait pas d'ou vient le probleme => je montre mes suites de test a l'autre developpeur, qui est ensuite convaincu que le probleme vient de son cote
- procedure ISO a suivre pour la validation des specs => j'associe a chaque fonctionnalite un test et mon rapport de test devient ma doc de validation
- je trouve un module super difficile a developper et a tester => c'est un signe de mauvaise conception, je le decoupe jusqu'a pouvoir le tester facilement
- on me dit que a la convergence de trois conditions tres tres rares, le soft ne marche pas => je modifie mon simulateur (pratique de l'avoir developpe avant) pour inclure ces conditions tres tres rares.
etc etc.
Les tests unitaires, c'est vraiment une methodologie de developpement qui me permet d'etre super zen dans ce que je fais et de gerer tous les problemes quotidiens avec du recul.
> Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Mon cauchemard, c'est les developpeurs qui pensent que leur cerveau demesure ne pond que du code correct.
Perso, je suis modeste et pessimiste. Je pense que le code que j'ecris ne marche pas. Alors, je cherche des preuves.
> Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
De fait, si tu les as utilise et que tu as vu leur valeur, je ne comprends pas pourquoi tu me critiques de facon aussi acharnee.
> J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
Ca rejoint ce que je disais sur la valeur des tests. Ca sert plus qu'au developpeur.
> Retard : 15 jours.
Chapeau!
> Le client ne s'est jamais plaint d'un bug.
C'est la caracteristique d'un programme avec de bons tests unitaires. Tres peu de bugs.
> Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Je pense que tu as pris des risques sur ton projet, que tu mesurais de facon consciente. Il aurait pu t'arriver des problemes, genre le client reviens au bout de 4 mois : "donnez nous ce que vous avez fait , et on arrete le projet. Puisque ca fait 4 mois que vous avez commence, vous en etes a la moitie. On paiera que pour ce qui marche uniquement".
Mais je ne critique pas ta demarche. C'est bien que tu aies reussie a faire ce qui paraissait impossible.