Discussion :

[Garulfo]

[...] Mais on ne "vérifie pas que ça plante".. On fait la même démarche qu'on ferait à la fin, "on vérifie que ça marche".... Et éventuellement on corrige les bugs...

Par contre, si tu enseignes, fais attention aux mots. Nous sommes dans un métier technique, et les mots ont un sens....

Essais/erreurs réfère à une "méthode" (ou plutôt une pratique) où on n'a pas de conception (pas de méthode), on ajoute une ligne pour voir si ça solutionne, .. Non ? bon ben on en essaye une autre...

Souviron, tu as complètement raison. Si Miles tu enseignes en utilisant un vocabulaire douteux, tu donnes une très mauvaise base à tes étudiants. Les mots ont un poids important dans la compréhension d'un processus, ce qui explique les définitions normalisées par exemple.

Mais, par contre, mon cher Souviron, en appliquant ce principe, on ne vérifie pas plus « que ça marche » qu'on ne vérifie « que ça plante », car les tests ne vérifient pas qu'un programme marche mais uniquement qu'il n'y a pas de nouvelle faute introduite, et a fortiori, cela augmente donc la confiance qu'on a dans le logiciel. À la limite, peut être pratiques-tu du model-checking dans ta branche, mais ça reste exceptionnel dans l'industrie. Mais sinon le but des tests traditionnels n'est que d'augmenter le niveau de confiance. Autrement, il n'y aurait pas tant de bug après mise sur site.
Comme le disait Hoare : « si tu n'as pas de bugs dans ton logiciel, c'est soit qu'il est trop petit pour en avoir, soit que tu ne les as pas encore découvert. »

Au passage, pour ceux qui s'intéresse aux tests, un nouveau livre est sorti il y a peu :
Software Testing and Analysis
Process, principles, and techniques
Mauro Pezzè and Michal Young
Wiley 2007.
D'avis de plusieurs collègues, ce livre est excellent.

Pis solutionner est un anglicisme... on t'a pas dit ça icite ?

[yphilogene]

Moi aussi, cette multiplication des langages m'inquiète. A un moment, il faut faire un choix et je crois que ce choix ne porte pas sur les capacités du langage en question mais sur la communauté (et non pas la force marketing) qui supporte le langage et le domaine d'application auquel il est particulièrement adapté.

C'est ainsi qu'en sortant d'école, j'ai choisi le JAVA, pour 2 raisons:
1) Pour sa communauté et le principe de JavaDoc.
2) Parce que je m'intéresse particulièrement aux applications d'entreprise.

Ensuite, il est vrai qu'à la base, j'ai aussi été séduit parce tout ce qui est portabilité, orientation objet, garbage collector, etc... Mais ce n'est pas cela qui m'a aidé à faire mon choix.

[souviron34]

Mais, par contre, mon cher Souviron, en appliquant ce principe, on ne vérifie pas plus « que ça marche » qu'on ne vérifie « que ça plante », car les tests ne vérifient pas qu'un programme marche mais uniquement qu'il n'y a pas de nouvelle faute introduite, et a fortiori, cela augmente donc la confiance qu'on a dans le logiciel. À la limite, peut être pratiques-tu du model-checking dans ta branche, mais ça reste exceptionnel dans l'industrie. Mais sinon le but des tests traditionnels n'est que d'augmenter le niveau de confiance. Autrement, il n'y aurait pas tant de bug après mise sur site.

Non, je parlais des "cycles rapides", où les test se font plutôt pas par tests unitaires, mais par vérification par l'utilisateur (et donc que "ça marche" )..

Maintenant, effectivement le sujet des tests est vaste et problématique....

J'aurais tendance à dire avec mon expérience que la manière de tester de l'industrie en général est relativement stupide (quelle que soit la méthode), et ne teste pas le logiciel, mais le programmeur...

En fait, de mon point de vue, la plupart de la philosophie "test unitaire" est inutile, si l'on est un bon programmeur. Faire une fonction qui fait "a+b" n'a aucunement besoin d'un test. De la même manière, transformer un tableau en liste chainée ou autre truc du style n'a, pour un programmeur expérimenté, aucune difficullté... Et a mon humble avis, toute cette armada repose sur la non-confiance dans les programmeurs, considérés par ces méthodologies comme des "pions" d'une chaîne de production, interchangeables et sans "colonne vertébrale" (d'où les découpages en conception détaillée, pseudocode, test unitaire, etc etc..).

Dans toute ma vie je n'ai JAMAIS fait de tests unitaires. Par contre, des tests fonctionnels, oui, en permanence..


Et bien que je puisse comprendre l'intérêt d'une métrique, et d'un cadre formel, je n'en ai vu aucun jusqu'à présent qui me satisfasse. Les 2 seuls pour moi étant "l'acceptance de l'utilisateur" (la fonctionalité) et la "solidité". (j'ai déjà dit quelque part ce qu'un testeur national m'a une fois dit pour un GUI, et que j'ai appliqué à la lettre dans tous mes softs par la suite : tu passes le test de la robustesse, tu as passé 85%...).

Pis solutionner est un anglicisme... on t'a pas dit ça icite ?

bah .. s'tu possible ? p'têt ben.. mais "nez en moins" j'ai toujours utilisé ça car plus compact que "trouver une bonne solution"

[GnuVince]

souviron: Je t'invite à lire ce chapître d'un livre sur Python: http://diveintopython.adrahon.org/un...ing/index.html

L'auteur veut écrire une fonction qui transforme un nombre décimal en nombre romain. La première chose qu'il va faire est écrire des tests pour vérifier que 4 devient 'IV' et pas 'IIII', etc.

Ses tests sont sa spécification, mais à la différence d'un document Word, ils sont exécutables. Quand les tests passent, le code fonctionne.

[souviron34]

Ses tests sont sa spécification,

Dans la réalité d'un projet industriel, ta spécification vient du cahier des charges..

Qui ne contient absolument rien d'informatique, ni de détaillé à ce niveau (exemple : "faire un déplacement d'image à la vitesse de la souris" )

[Matthieu Brucher]

Non, je parlais des "cycles rapides", où les test se font plutôt pas par tests unitaires, mais par vérification par l'utilisateur (et donc que "ça marche" )..

Le genre de tests qui sont difficiles à vérifier à la longue (même si certains tests de ce genre sont dans certains cas indispensable, c'est ce qui est fait sur les téléphones portables par exemple).

En fait, de mon point de vue, la plupart de la philosophie "test unitaire" est inutile, si l'on est un bon programmeur. Faire une fonction qui fait "a+b" n'a aucunement besoin d'un test. De la même manière, transformer un tableau en liste chainée ou autre truc du style n'a, pour un programmeur expérimenté, aucune difficullté... Et a mon humble avis, toute cette armada repose sur la non-confiance dans les programmeurs, considérés par ces méthodologies comme des "pions" d'une chaîne de production, interchangeables et sans "colonne vertébrale" (d'où les découpages en conception détaillée, pseudocode, test unitaire, etc etc..).

Je suis presque d'accord avec toi. Presque parce que je suis bien content d'avoir des tests unitaires et des tests "fonctionnels" dans mon application. Les tests unitaires m'ont permis de résoudre pas mal de problèmes dans le code que j'ai écrit, et sans eux, j'aurai introduit bien des régressions. MAis ce qui m'intéresse surtout, c'est que les tests fonctionnels passent

Dans la réalité d'un projet industriel, ta spécification vient du cahier des charges..

Qui ne contient absolument rien d'informatique, ni de détaillé à ce niveau (exemple : "faire un déplacement d'image à la vitesse de la souris" )

Effectivement, il y a une étape intermédiaire entre les deux. Et trouver les tests corrects sous-entendus par le client, c'est pas toujours facile, mais bon, ce sont des tests fonctionnels, les tests unitaires, c'est plus pour l'équipe, à mon avis (mais la frontière est floue).

[GnuVince]

Dans la réalité d'un projet industriel, ta spécification vient du cahier des charges..

Qui ne contient absolument rien d'informatique, ni de détaillé à ce niveau (exemple : "faire un déplacement d'image à la vitesse de la souris" )

Si tu peux faire un programme avec ton cahier des charges, tu peux certainement en faire des tests automatisés.

Peut-être que tu est moins paresseux que moi, mais après 3 fois que j'ai testé une fonction manuellement, je suis tanné, écoeuré, je veux plus rien savoir. C'est pour ça que j'écris des tests, pour que mon impatience, ma paresse et mon écoeurantite aigüe ne viennent pas faire en sorte que le logiciel est mal testé. J'écris les tests une fois, je les modifies quelques fois au besoin, et je peux les exécuter des centaines de fois.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$ find . -name 'tests.py' | xargs grep assert | wc -l
1225
$ python manage.py test
.............................................................................................................................................................................................
----------------------------------------------------------------------
Ran 189 tests in 74.915s

OK

En 1 minute et 15 secondes, 1200+ assertions on été exécutées pour s'assurer que le logiciel fonctionne comme on s'y attend. Je ne pourrais pas tester tout ça manuellement, ça serait long, plate et je ferais certainement des erreurs.

[souviron34]

Si tu peux faire un programme avec ton cahier des charges, tu peux certainement en faire des tests automatisés.

Peut-être que tu est moins paresseux que moi, mais après 3 fois que j'ai testé une fonction manuellement, je suis tanné, écoeuré, je veux plus rien savoir. C'est pour ça que j'écris des tests, pour que mon impatience, ma paresse et mon écoeurantite aigüe ne viennent pas faire en sorte que le logiciel est mal testé. J'écris les tests une fois, je les modifies quelques fois au besoin, et je peux les exécuter des centaines de fois.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$ find . -name 'tests.py' | xargs grep assert | wc -l
1225
$ python manage.py test
.............................................................................................................................................................................................
----------------------------------------------------------------------
Ran 189 tests in 74.915s

OK

En 1 minute et 15 secondes, 1200+ assertions on été exécutées pour s'assurer que le logiciel fonctionne comme on s'y attend. Je ne pourrais pas tester tout ça manuellement, ça serait long, plate et je ferais certainement des erreurs.

Ah bon ? tu peux simuler le fait que l'utilisateur a un coup de tel, et en se tournant a le combiné qui appuie pendant 5 minutes sur la touche F5 ???
(en passant par ALT et Delete bien entendu )

Tu peux déduire du fait que FonctionA fait ce qu'il faut, de même que fonctionB et FonctionC, mais que quand l'utilisateur double clique sur A, puis sans attendre la fin (ce qui était prévu) clique sur B, la mise à jour temps réel de ta BD est coincée ??

Bravo.. Je te tire mon chapeau.. Tu devrais immédiatement te présenter comme le Testeur de l'Année...

[Garulfo]

Non, je parlais des "cycles rapides", où les test se font plutôt pas par tests unitaires, mais par vérification par l'utilisateur (et donc que "ça marche" )..[...]

Donc tu parles de validation. Mais même là, on n'a pas que cela marche, mais que cela semble convenir à l'utilisateur (et donc +xx% dans la balance)
Pour ta réflexion sur les tests unitaires tu n'as pas complètement tort.
Ils sont souvent dû à une surcharge (dans le sens « trop chargée ») fonctionnelle. On veut en faire trop dans une fonction et on néglige une décomposition modulaire correcte (souvent en prétextant un manque de performance qui est pourtant une cause négligeable de problème en général).
De fait, on crée des fonctions (ou des méthodes ont s'en fout) qui perdent en clarté et on a besoin des tests unitaires. J'acquiesce donc. Mais, car il y a toujours un « mais », la programmation impérative et les effets de bords (donc le non respect d'une bonne programmation modulaire en fait) mène à obtenir un comportement plus complexe d'un point de vue logique. Dès lors, les tests unitaires apparaissent comme non négligeable si ce n'est comme nécessaire. Ils permettent de s'assurer que des modif' ultérieur soient sans danger.

Attention aussi aux termes, un test unitaire peut être fonctionnel. Je pense que tu voulais dire des tests systèmes ou des tests d'intégration. J'ai un petit peu d'expertises dans ce domaine et donc je suis tatillon avec les termes même si ma spécialité reste le formel.

bah .. s'tu possible ? p'têt ben.. mais "nez en moins" j'ai toujours utilisé ça car plus compact que "trouver une bonne solution"

Et « résoudre » ?? N'est ce pas un verbe formidable ?
Menfinbon je pense que le français survivra à ça.

[Garulfo]

souviron: Je t'invite à lire ce chapître d'un livre sur Python: http://diveintopython.adrahon.org/un...ing/index.html

L'auteur veut écrire une fonction qui transforme un nombre décimal en nombre romain. La première chose qu'il va faire est écrire des tests pour vérifier que 4 devient 'IV' et pas 'IIII', etc.

Ses tests sont sa spécification, mais à la différence d'un document Word, ils sont exécutables. Quand les tests passent, le code fonctionne.

Attention, d'une part tu ne vas pas faire tous les tests engendrés par la spécification... à moins que tu ne prennes une approche par model-checking. Ensuite, les tests issus des spécifications (tests systèmes) ne sont pas suffisants pour établir la validité (et donc l'exactitude) d'un programme au plus haut niveau. Ils restent les tests d'acceptation qui sont fondamentaux puisque un programme peut marcher, respecter la spécification mais échouer dans les tests de validation à cause d'une erreur durant le processus de spécification à l'analyse des besoins. C'est ce que Souviron entend par « les tests viennent du cahier des charges » et il a encore une fois raison (tu devrais accepter que son expérience n'est pas forcément inintéressante et dépasser). Ce sont les pires des erreurs et les plus coûteuses d'après les études statistiques menées par Boehm. Finalement, sans remettre en cause le moins du monde la compétence de Mark Pilgrim dans le domaine du Web et de Python, ce n'est pas un spécialiste des tests. D'ailleurs il ne se proclame pas comme tel. L'approche présentée dans ce chapitre (que je viens de lire merci pour ton lien) est très bonne pour des débutants et pour introduire aux mondes capricieux de la qualité logiciel. Mais c'est très léger et ne s'appliquera pas partout.

[Garulfo]

Si tu peux faire un programme avec ton cahier des charges, tu peux certainement en faire des tests automatisés.[...]

En théorie tu n'as pas tort. En pratique ça ne marche pas.
Deux raisons à cela, la complexité des évènements (les exemples que te donne Souviron sont de cet ordre, même s'ils ont baigné un peu dans l'ironie... n'est-il point?) et la difficulté de réaliser l'oracle.

Tu te places dans un contexte de programme qui n'effectue qu'un calcul. L'automatisation du test est alors plus « évidente » (on note les guillemets merci)... mais dans un cadre où l'interaction devient primordiale par une série d'évènements externes, il est difficile de dire ce qu'est un « bon » résultat... parfois des besoins sont difficiles à quantifier :
« besoin de convivialité : l'interface du programme devrait être assimilable en moins d'une heure par qqun qui n'importe quel arbitre de tennis qui connait l'utilisation d'un ordinateur d'une façon courante. »
Comment tu tests tu ce besoin toi ?

Si tu t'intéresse aux tests automatisés, j'ai de la documentation et des articles de recherches en masse là dessus si tu as le niveau technique suffisant (fin de bac minimum, i.e. fin de licence pour les français) je peux te les montrer. Ça demande de belles connaissances en GL et en math (des méthodes formelles donc).

[souviron34]

Donc tu parles de validation. Mais même là, on n'a pas que cela marche, mais que cela semble convenir à l'utilisateur (et donc +xx% dans la balance)
...la programmation impérative et les effets de bords (donc le non respect d'une bonne programmation modulaire en fait) mène à obtenir un comportement plus complexe d'un point de vue logique. Dès lors, les tests unitaires apparaissent comme non négligeable si ce n'est comme nécessaire. Ils permettent de s'assurer que des modif' ultérieur soient sans danger.

Attention aussi aux termes, un test unitaire peut être fonctionnel. Je pense que tu voulais dire des tests systèmes ou des tests d'intégration. J'ai un petit peu d'expertises dans ce domaine et donc je suis tatillon avec les termes même si ma spécialité reste le formel.
...

Effecitvement je parlais de validation. Mais dans mon expérience (et ma "croyance", ma philosophie de base), ce sont les seuls valables. On ne fait pas un logiciel pour correspondre à une norme ou à un processus... On fait un logiciel pour satisfaire un besoin de l'utilisateur....

En fait, ce que je veux dire, c'est que si tu vas voir un ébéniste et que tu lui dis : "je voudrais une table en marquetterie qui fait 3 mètres par 2, ovale, d'environ 2cm d'épaisseur", tu es d'accord (ou non) avec le devis, et puis tu le laisses tranquille jusqu'à ce qu'il te téléphone "c'est prêt".. Pendant ce temps-là, lui, il travaille avec son EXPERTISE, il se fait des schémas à lui, il a sa manière de faire, mais justement ce qui distingue l'ébéniste du gars qui coupe les planches chez (Castorama, Rona, etc..) , c'est son expertise...
Sa "méthode" de fabrication est certes une "méthode", mais ce à quoi lui a servi son apprentissage (et éventuellement sa "tournée" de "compagnon"), c'est justement à maitriser un art. Il ne va pas tester chaque étape de ce qu'il fait PARCE QUE il est expert.

Et c'est ça que je reproche au système des "tests unitaires" (dans le sens du cycle en V : chaque fonction identifiée doit avoir son plan de test et son test spécifique) et dans les grosses équipes : cela repose sur l'affirmation que l'on ne peut faire confiance à l'expertise.. On a affaire qu'à des "ouvriers" non 'spécialisés.. Pour ma part, je considère que nous sommes plus artistes ou artisans (création) qu'ouvriers. Je me considère plus comme l'ébéniste que comme le coupeur de bois sachant manipuler sa grosse scie....

Mais il est vrai que je ne viens pas d'une formation informatique

[GnuVince]

Les tests unitaires ne sont pas le "holy grail" ou le "silver bullet" de la fiabilité logicielle, si j'ai laissé cette impression, c'était pas mon intention. Mais je crois qu'ils restent un outil extrêmement important pour le développement d'applications solides. Non je peux pas tester ce qui arrive quand un usager pèse 4 fois sur la touche 'Ctrl' avec son petit orteil, et je vois mal comment n'importe quel programmeur pourrait envisager cette probabilité.

Ce que je peux assurer par contre, c'est le bon fonctionnement de mes fonctions. Dans l'exemple que j'ai donné plus haut, j'ai une fonction schedule_conflict() qui prend deux événements qui ont une heure de début et une heure de fait et qui retourne True si les événements entrent en conflit (les périodes se superposent) et False s'il y en a pas.

Ce que j'ai fait a été de créer un test (une unité) qui comporte 7 ou 8 assertions qui couvrent les cas possibles. J'ai ensuite écrit ma fonction et je me suis arrêté lorsque mon test passait. Est-ce que ce genre de tests est inutile à votre avis? Moi, je ne pense pas.

[Garulfo]

Effecitvement je parlais de validation. Mais dans mon expérience (et ma "croyance", ma philosophie de base), ce sont les seuls valables. On ne fait pas un logiciel pour correspondre à une norme ou à un processus... On fait un logiciel pour satisfaire un besoin de l'utilisateur....[...]

Mais il est vrai que je ne viens pas d'une formation informatique

Mais tu n'as pas tort.
Supposons que les tests de validation passent alors que les tests unitaires ne passent pas: le logiciel est acceptable donc (acceptance tests en anglais ce n'est pas pour rien.)
Et inversement si tous les tests passent sauf ceux de validation, le projet est à jeter. Il existe de nombreux exemples qui ont coûté des milliards et qui servent d'illustrations à l'importance d'une analyse des besoins bien faîtes.

Encore une fois, pour les tests unitaires, je comprends ton point de vue, et comme je l'ai dit, je suis en accord sur le principe. Cependant, force est de constater que le meilleur développeur peut passer à côté d'une erreur grossière bien malgré lui... et la relecture ne l'aidera pas. Combien de fois sommes nous passé à côté d'un « = » qui aurait dû être un « == » ou d'un détail qui manquait alors que le compilateur nous disait qu'il y avait une erreur là ! C'est un problème humain. Vérifier l'exactitude d'un programme / d'une fonction est une approche destructive (objectivement, on cherche à montrer que la fonction ne marche pas) et l'activité de développement est constructive. Puis, il y a la raison cognitive, nous ne fonctionnons pas comme un ordinateur par traitement de chaque élément mais par survol du tout (par exemple, nous lisons plusieurs mots ensemble et les reconstituons après la lecture pour leurs donner un sens... nous ne lisons pas mot par mot ni, a fortiori, lettre par lettre).

Tout ceci, fait qu'il est légitime de douter de la confiance des développeurs. C'est en quelques sortes une activité non humaine que de comprendre le sens d'un programme. Dans un domaine comme celui dans lequel tu œuvres, il est dès lors exclu de fonctionner sans tests unitaires.

L'exemple que tu donnes pour l'ébéniste pourrait être très pertinent, mais même dans un tel processus on retrouve des « tests unitaires ». À ma connaissance (mon père travaillait avec des très nombreux charpentiers ), il y a une vérification constante du détail... tu coupes sur la scie verticale et, hop, tu vérifies en passant la main que sa semble correcte, puis à l'œil tu regardes que ça ne dépasse pas 2 cm. Si tu as un doute tu fais un examen plus approfondi... À moins que l'outil le vérifie pour toi. La différence c'est que tu travailles sur un objet physique et qu'on assimile plus facile les contraintes d'un monde physique puisque nous sommes en contact sensoriel avec lui. Les perceptions sont essentiels à notre « intelligence » au sens large.

[Garulfo]

Les tests unitaires ne sont pas le "holy grail" ou le "silver bullet" de la fiabilité logicielle, si j'ai laissé cette impression, c'était pas mon intention. Mais je crois qu'ils restent un outil extrêmement important pour le développement d'applications solides. Non je peux pas tester ce qui arrive quand un usager pèse 4 fois sur la touche 'Ctrl' avec son petit orteil, et je vois mal comment n'importe quel programmeur pourrait envisager cette probabilité.

Ce que je peux assurer par contre, c'est le bon fonctionnement de mes fonctions. Dans l'exemple que j'ai donné plus haut, j'ai une fonction schedule_conflict() qui prend deux événements qui ont une heure de début et une heure de fait et qui retourne True si les événements entrent en conflit (les périodes se superposent) et False s'il y en a pas.

Ce que j'ai fait a été de créer un test (une unité) qui comporte 7 ou 8 assertions qui couvrent les cas possibles. J'ai ensuite écrit ma fonction et je me suis arrêté lorsque mon test passait. Est-ce que ce genre de tests est inutile à votre avis? Moi, je ne pense pas.

Je ne le pense pas pour les raisons cités ci-dessus. Mais encore une fois, si tu peux le faire c'est parce que tu es dans un cadre très particulier. Faire les tests de manière exclusif n'est pas toujours faisable. De plus, tu passes par une approche intuitive et donc tu peux, involontairement, passer à côté d'élément clé. Restes finalement, que LES seuls vrais tests sont, en quelque sorte, les tests de validation. C'est eux qui décident de l'avenir de ton projet dans un cadre réel. D'où, encore une fois, l'importance fondamentale de l'ingénierie des besoins. En fait, statistiquement, les projets qui échouent ont en commun des erreurs introduites dans l'ingénierie des besoins. Les autres projets sont souvent rattrapables, ces derniers le sont beaucoup plus rarement. Et les coûts de maintenance le montre aussi. C'est définitivement l'analyse des besoins qui coûte le plus cher en effort dans le développement d'un système logiciel. À la vue de ça, les tests unitaires, qui ne valident quasiment rien dans les besoins, ont l'air négligeable.

[GnuVince]

Je ne le pense pas pour les raisons cités ci-dessus. Mais encore une fois, si tu peux le faire c'est parce que tu es dans un cadre très particulier. Faire les tests de manière exclusif n'est pas toujours faisable. De plus, tu passes par une approche intuitive et donc tu peux, involontairement, passer à côté d'élément clé. Restes finalement, que LES seuls vrais tests sont, en quelque sorte, les tests de validation. C'est eux qui décident de l'avenir de ton projet dans un cadre réel. D'où, encore une fois, l'importance fondamentale de l'ingénierie des besoins. En fait, statistiquement, les projets qui échouent ont en commun des erreurs introduites dans l'ingénierie des besoins. Les autres projets sont souvent rattrapables, ces derniers le sont beaucoup plus rarement. Et les coûts de maintenance le montre aussi. C'est définitivement l'analyse des besoins qui coûte le plus cher en effort dans le développement d'un système logiciel. À la vue de ça, les tests unitaires, qui ne valident quasiment rien dans les besoins, ont l'air négligeable.

T'as beau parler français, je catch pas une criss d'affaire de ce que tu dis. "Les raisons cités [sic] ci-dessus?" "Je suis dans un cadre particulier?" "Faire des tests de manière exlusif [sic]?" "Une approche intuitive?" C'est quoi ta définition de tests de validation? Usager qui essaye l'application? Manager qui a la spec dans une main, la souris dans l'autre et qui test tout manuellement? "Ingénierie des besoins?" Si l'usager a indiqué son besoin, pourquoi ne pas l'exprimer en code qui puisse s'exécuter et se vérifier? "les tests unitaires, qui ne valident quasiment rien dans les besoins, ont l'air négligeable?" Si le client dit que deux rendez-vous ne peuvent pas se chevaucher, c'est un besoin qu'il exprime, et ce besoin peut s'exprimer sous forme de code.

Et si les tests unitaires sont inutiles, comment ce fait-il que tous les projets open source que j'utilise ou sur lesquels je contribue ont une suite très extensive de tests?

[souviron34]

T'as beau parler français, je catch pas une criss d'affaire de ce que tu dis. "Les raisons cités [sic] ci-dessus?" "Je suis dans un cadre particulier?" "Faire des tests de manière exlusif [sic]?" "Une approche intuitive?" C'est quoi ta définition de tests de validation? Usager qui essaye l'application? Manager qui a la spec dans une main, la souris dans l'autre et qui test tout manuellement? "Ingénierie des besoins?" Si l'usager a indiqué son besoin, pourquoi ne pas l'exprimer en code qui puisse s'exécuter et se vérifier? "les tests unitaires, qui ne valident quasiment rien dans les besoins, ont l'air négligeable?" Si le client dit que deux rendez-vous ne peuvent pas se chevaucher, c'est un besoin qu'il exprime, et ce besoin peut s'exprimer sous forme de code.

Et si les tests unitaires sont inutiles, comment ce fait-il que tous les projets open source que j'utilise ou sur lesquels je contribue ont une suite très extensive de tests?

Tu melanges plusieurs choses... Je conviens () comme le dit Garulfo que l'on ne peut se faire (ou a d'autres) confiance absolue... Et que des tests "unitaires" (notez bien les guillemets) sont necessaires (je met des guillements car je pense qu'autant cela "peut" se justifier pour une fonctionalite relativement complexe, autant c'est inutile pour une simple routine (mais pourtant necessaire d'apres les normes en vigueur)).

Donc, ni Garulfo (au contraire) ni moi ne disons que les tests sont inutiles. Simplement que la problematique des tests est complexe.

Visiblement tu n'as pas l'experience de gros logiciels (ce n'est pas une critique, juste une constation). En effet, lorsque tu l'as, tu sais que

Si l'usager a indiqué son besoin, pourquoi ne pas l'exprimer en code qui puisse s'exécuter et se vérifier?

est TRES RAREMENT le cas (et heureusement, sinon le client pourrait faire le soft a ta place et tu n'aurais pas de travail...). Le client exprime son besoin dans SES termes, avec SES contraintes, parfois floues, parfois precises, mais de toutes facons NON LIEES en general a l'informatique "mesurable" ou "testable" facilement (exemple : accelerer de 10% le temps de traitement par rapport a la situation actuelle).
Et meme si l'on arrive a le tester, ce n'est que par analyse 1) de ce qui est fait a l'heure actuelle, et 2) de ce que fait le logiciel fini... Donc oublie les tests unitaires pour ca...

D'autre part, tu sais egalement que

"les tests unitaires, qui ne valident quasiment rien dans les besoins, ont l'air négligeable?"

est vrai dans 99% des cas de figure... Car le temps passe en maintenance ou en modification du code d'un code ne correspondant pas a la structure de "pensee" de l'utilisateur (par exemple modification d'architecture necessaire) est sans rapport (de l'ordre d'un facteur 100 minimum en temps et/ou main d'oeuvre en plus) par rapport a la correction d'un bug, aussi gros soit-il...

Le pire qu'il me soit arrive de passer ces dernieres annees a ete 10 jours sur un bug... Mais 1 an 1/2 sur une erreur d'architecture....

Et enfin les projets OpenSource ne sont pas la panacee, et a ma connaissance ne sont pas utilises dans des appareils ou des vies humaines sont en jeu.... Et meme sans parler de ce type de logiciel, j'ai avec un collegue passe 3 ans (bon, pas a temps plein, mais quand memem a temps plein environ 2 a 3 mois) a corriger les bugs/imprecisions du source de HTTP...

[Garulfo]

T'as beau parler français, je catch pas une criss d'affaire de ce que tu dis. "Les raisons cités [sic] ci-dessus?" "Je suis dans un cadre particulier?" "Faire des tests de manière exlusif [sic]?" "Une approche intuitive?" C'est quoi ta définition de tests de validation? Usager qui essaye l'application? Manager qui a la spec dans une main, la souris dans l'autre et qui test tout manuellement? "Ingénierie des besoins?" Si l'usager a indiqué son besoin, pourquoi ne pas l'exprimer en code qui puisse s'exécuter et se vérifier? "les tests unitaires, qui ne valident quasiment rien dans les besoins, ont l'air négligeable?" Si le client dit que deux rendez-vous ne peuvent pas se chevaucher, c'est un besoin qu'il exprime, et ce besoin peut s'exprimer sous forme de code.

Et si les tests unitaires sont inutiles, comment ce fait-il que tous les projets open source que j'utilise ou sur lesquels je contribue ont une suite très extensive de tests?

Franchement tu ne fais pas d'effort là.
J'ai dis plusieurs fois que je comprenais Souviron, mais que les tests unitaires ne sont pas inutiles justement.

Ingénierie des besoins, tests de validation, te sont des termes inconnus ? Ils sont pourtant clairement définis dans de nombreux manuels, en anglais ou en français. Un bon début est sur wikipedia en français (tests de validation)
http://fr.wikipedia.org/wiki/Test_de_validation
ou en anglais (acceptance testing)
http://en.wikipedia.org/wiki/Acceptance_testing
Ce sont les tests effectués directement par le client (pas dans le sens commercial, mais dans le sens celui qui a commandité le système).

Ceci prouve que tu as une méconnaissance du domaine du génie logiciel et que tu devrais te montrer modeste et circonspect dans tes remarques plutôt que d'être un tantinet aggressif.

Et ce n'est pas parce que les projets open-source que tu utilises ou ceux sur lesquelles tu contribues font une forte utilisation de tests unitaires que ceux-ci sont une panacée. Un principe statistique dit qu'on ne peut voir les principes généraux correctement si on se contente de regarder ce qu'il y a autour de nous. Ce que je soutiens n'est pas dû à moi (hélas, cela m'aurait rendu célèbre) mais à tout une suite d'auteur et de travaux fait avant moi.

Si l'usager a indiqué son besoin, pourquoi ne pas l'exprimer en code qui puisse s'exécuter et se vérifier?

Parce que ce n'est tout simplement pas toujours faisable. Particulièrement dans le problème de la convivialité humain-machine (donc qui touche le IHM/HMI). Par exemple :
« besoin de convivialité : l'interface du programme devrait être assimilable en moins d'une heure par n'importe quel arbitre de tennis qui connait l'utilisation d'un ordinateur d'une façon courante. »
Une grande partie des efforts informatiques commencent à s'orienter vers le problème de la convivialité. Et il était temps. Un des exemples, anecdotique certes mais réel, de ceci est la nouvelle Wii. On commence à repenser les interfaces. La convivialité se teste mal. Mais cela fait partie des besoins fonctionnels d'un système pourtant. Les tests unitaires ne peuvent absolument rien pour toi dans ce cas.

[souviron34]

La convivialité se teste mal. Mais cela fait partie des besoins fonctionnels d'un système pourtant. Les tests unitaires ne peuvent absolument rien pour toi dans ce cas.

Et j'ajouterais que, pour l'utilisateur, c'est l'ESSENTIEL... (sauf dans le cas des anciennes applis Windows, qui plantaient tout le temps avec "Fatal Error #00"3xFFE" , très convivial comme message d'erreur....).

@GnuVince: le détail particulier est important, mais je te citerais juste un exemple : j'ai travaillé il y a .. 12 ans sur un logiciel médical (dans un grand Hôpital de Montréal). Une certaine fonctionalité était la prescription par les médecins (les feuilles d'ordonnance). Le logiciel avait passé absolument TOUS les tests unitaires, et avait été développé avec méthode... MAIS il était refusé par les "clients", utilisateurs, appelle-ça comme tu veux.. Pourquoi ?? Parce qu'à la main ils mettaient 12 minutes à remplir une feuille , et qu'avec l'informatique ils mettaient ..... 45 minutes.....

Donc oui la fonctionalité était là, parfaitement fonctionnelle...
Mais le logiciel était inutilisable.

Résultat : alors qu'une correction de bug peut prendre, aller, au gros max environ 2 à 3 semaines (en refaisant tous les tests), là il a fallu 2 ans de 60 personnes et 5 millions de $ pour corriger ça....

[GnuVince]

souviron34: Merci pour ton exemple. Et oui, je suis *parfaitement* d'accord que si un logiciel rend une tâche plus longue, complexe, hardue, etc. pour les usagers, ça donne rien, même si le fonctionnement est parfait. D'un autre côté, un logiciel qui est facile et rapide d'utilisation par les utilisateurs, mais qui plante, qui donne des résultats erronés, etc. n'est pas plus utile, on est d'accord?

Les deux types de tests sont complémentaires. Comme j'ai dit dans un autre message, je veux pas faire passer l'impression que si les tests unitaires passent que le logiciel est parfait. Je dis que les tests unitaires assurent que le programme exécute les fonctions comme on s'y attend. Pour moi, en tant que programmeur, ça m'indique si un changement que j'ai fait affecte le bon fonctionnement du système. Les tests par les usagers vont révéler si l'interface du logiciel est bien conçue.