debug de fuites memoire

Michel Michaud wrote:

Je ne vois pas en quoi cela empêche de tout tester ce que *vous*
avez écrit. Tu peux élaborer ?

À part qu'élaborer est un anglicisme (ça c'est à propos d'une discussion
précedente), je suis d'accord avec Matthieu (par chez nous, on dirait
plutôt « développer » que « élaborer » qui n'est que la transposition
(et non la traduction) de « elaborate »).

En plus de cela, il se peut que pour des raisons très diverses
(notamment historiques), le produit n'ait pas été testé selon les règles
de l'art. Mais, plus la combinatoire des entrées est importante, plus
l'exhaustivité des tests est illusoire. Or, pour une bibliothèque de
classes, la combinatoire des entrées est concrètement indémerdable.

Si par « tester tout ce que vous avez écrit », tu entends « tests
unitaires », je te répondrais que cela ne suffit pas pour certains type
de classes comme des classes gérant des connexions réseau. Pour
celles-là, les tests unitaires me paraissent bien difficile à mettre en
oeuvre, par exemple, notamment parce qu'on ne peut tester « unitairement
» une classe qui ne peut fonctionner qu'avec d'autres classes.

Arnaud

Dans le message 42dfc9a9$0$8171$626a14ce@news.free.fr,

Michel Michaud wrote:

Je ne vois pas en quoi cela empêche de tout tester ce que *vous*
avez écrit. Tu peux élaborer ?

À part qu'élaborer est un anglicisme

Merci, je crois que c'était ma première utilisation de cette
expression à vie (ou depuis très très longtemps), mais j'avoue ne
pas avoir penser à l'anglicisme même si je devais le savoir...

[...]

Si par « tester tout ce que vous avez écrit », tu entends « tests
unitaires », je te répondrais que cela ne suffit pas pour certains
type de classes comme des classes gérant des connexions réseau. Pour
celles-là, les tests unitaires me paraissent bien difficile à
mettre en oeuvre, par exemple, notamment parce qu'on ne peut tester
« unitairement » une classe qui ne peut fonctionner qu'avec
d'autres classes.

Je comprends bien qu'on ne peut pas tout tester. J'ai fait ma
remarque initiale, un peu provocatrice je l'accorde, parce que
tu pouvais sembler dire (je dis bien pouvais sembler) que vous
ne faisiez pas tellement de tests puisque, de toute façon, vous
faisiez des bibliothèques, etc.

En fait, je me rends compte que j'ai surtout pensé que les
bibliothèques sont souvent des ensembles de parties assez
indépendantes, donc plus naturelles à tester en isolation. On
peut faire de même avec un logiciel complet, mais il faut être
méthodique (par exemple, avec des classes appuyés par des tests
unitaires). Et il est plus facile de tester des parties
indépendantes que de tester un tout...

Il y aurait beaucoup à discuter sur les tests, c'est le sujet
de plusieurs bons livres... D'ailleurs je n'ai pas fini de lire
« Effective Software Testing » (sic) :-)

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Michel Michaud wrote:

Je comprends bien qu'on ne peut pas tout tester. J'ai fait ma
remarque initiale, un peu provocatrice je l'accorde, parce que
tu pouvais sembler dire (je dis bien pouvais sembler) que vous
ne faisiez pas tellement de tests puisque, de toute façon, vous
faisiez des bibliothèques, etc.

J'ai dit très précisément :
«
Par ailleurs, dans ma boîte, on fait des bibliothèques et non des
produits finaux. Et là, la palette possible d'utilisations est beaucoup
plus grande que dans une application compilée une bonne fois pour toute.
Tester tous les cas peut devenir particulièrement délicat.
»

Je pensais exprimer la même chose ou très sensiblement la même chose que :
«
Mais, plus la combinatoire des entrées est importante, plus
l'exhaustivité des tests est illusoire. Or, pour une bibliothèque de
classes, la combinatoire des entrées est concrètement indémerdable.
»

En fait, je me rends compte que j'ai surtout pensé que les
bibliothèques sont souvent des ensembles de parties assez
indépendantes, donc plus naturelles à tester en isolation.

Malheureusement, dans mon cas, ce n'est guère le cas.

Il y aurait beaucoup à discuter sur les tests, c'est le sujet
de plusieurs bons livres... D'ailleurs je n'ai pas fini de lire
« Effective Software Testing » (sic) :-)

Si tu as de très bons livres à conseiller, n'hésite pas.

Arnaud

Dans le message 42e00c24$0$8676$626a14ce@news.free.fr,

Michel Michaud wrote:

Je comprends bien qu'on ne peut pas tout tester. J'ai fait ma
remarque initiale, un peu provocatrice je l'accorde, parce que
tu pouvais sembler dire (je dis bien pouvais sembler) que vous
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[...]

J'ai dit très précisément :
[...]

Je pensais exprimer la même chose ou très sensiblement la même
chose que : «

Oui, c'est ce que tu as dit, mais il y avait une tournure qui,
au moins pour moi, laissait un doute (je crois que c'est la partie
« on fait des bibliothèques et non des produits finaux »...).

Par ailleurs, je ne peux pas discuter de la pertinence ou non de
tests plus exhaustifs dans votre cas, je n'ai pas tous les détails.
Je vous fais confiance :-)

[...]

Il y aurait beaucoup à discuter sur les tests, c'est le sujet
de plusieurs bons livres... D'ailleurs je n'ai pas fini de lire
« Effective Software Testing » (sic) :-)

Si tu as de très bons livres à conseiller, n'hésite pas.

Celui-là est pas si mal, et est le plus pratique et réaliste de
ceux que j'ai lus (au moins deux autres récemment, qui ne m'ont
pas laissé de souvenirs particuliers !). Un peu comme les autres
titres de la série « Effective XYZ », l'effort de le lire semble
valoir la peine, mais je n'ai pas encore fini de le lire, là je
me suis plutôt mis à lire « Advanced Unix Programming Second
Edition », que j'ai commandé après que Gabriel en ait parlé ici.

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Michel Michaud wrote:

Oui, c'est ce que tu as dit, mais il y avait une tournure qui,
au moins pour moi, laissait un doute (je crois que c'est la partie
« on fait des bibliothèques et non des produits finaux »...).

J'ai dû parler d'« application finale ». Parce que nos bibliothèques
sont des produits, quand même.

Je crois sincèrement que la testabilité n'est pas la même sur un
ensemble ouvert comme une bibliothèque et sur une application finale où
l'utilisation est, malgré tout, mieux maîtrisée.

Je vous fais confiance :-)

Merci. :-)

Arnaud

Matthieu Moy wrote:

"Michel Michaud" <mm@gdzid.com> writes:

Dans le message vpqd5pc9slb.fsf@ecrins.imag.fr, Matthieu Moy

[...] test exhaustif [...]

Ce n'est pas ce que je demande. Arnaud disait

Un peu quand même, non ? ...

[...] Tester tous les cas peut devenir particulièrement délicat.
^^^^^^^^^^^^

(et dans le message auquel je réponds, tu parles de « tout
tester », ce qui est clairement impossible).

Je demande simplement pourquoi il serait plus difficile de
tester (normalement, le mieux possible, selon l'art, etc.)
dans son cas que dans le cas général.

Je ne sais pas ce que fait Arnaud, donc je risque de répondre
à coté, mais il y a quand même des cas ou le profil
utilisateur est plus prédictible que d'autres. Si tu fais un
serveur web, tu peux raisonnablement supposer que
l'utilisateur s'en servira comme serveur web. Si tu fais un
traitement de texte, tu peux raisonnablement supposer que
l'utilisateur s'en servira comme d'un traitement de texte
(quoique ...). Si tu fais une bibliothèque de composants un
peu génériques, tu peux difficilement savoir pour quoi elle
sera utilisée, donc, tu as plus de chances de tomber sur un
client qui a un « mauvais » profile utilisateur.

Mais qu'est-ce que le profile utilisateur a à faire dedans ?
Chaque composant a un contrat. Tu testes bien toutes les clauses
du contrat. (À la limite, tu ne testes pas où le contrat dit
comportement indéfini.) Dans chaque clause, tu effectues des
tests exhaustifs autours des bornes et des points critiques, et
des échantionnages un peu partout ailleurs.

Ensuite, si jamais tu trouves une erreur, tu évalues le
processus, pour savoir comment ça ait pu produire (parce que
pour chaque erreur tu trouves, il faut supposer qu'il y en a
d'autres qui passe à travers tes tests). Et tu modifies le
processus pour que le cas ne se reproduit pas. En somme, si tes
tests détectent une erreur, c'est que tu as fait quelque chose
de faux plus en aval. (Je parle ici des tests de reception,
d'acceptation, d'homologation, ou comment tu veux les
appeler. Je conçois bien qu'il puisse avoir des erreurs dans les
tests unitaires effectués par le programmeur sur une classse
isolée. Encore qu'avec de l'expérience dans un processus bien
conduits, j'ai pû constater que même ces erreurs deviennent
plutôt rare.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr writes:

Mais qu'est-ce que le profile utilisateur a à faire dedans ?

Relis mon message un tout petit peu plus haut dans ce thread.

Chaque composant a un contrat. Tu testes bien toutes les clauses
du contrat.

Tiens, toi aussi, tu as une méthode de test exhaustive ?

Contacte vite mon labo, y'a un scoop ...

--
Matthieu

Arnaud Meurgues wrote:

Michel Michaud wrote:

Je ne vois pas en quoi cela empêche de tout tester ce que
*vous* avez écrit. Tu peux élaborer ?

À part qu'élaborer est un anglicisme (ça c'est à propos d'une
discussion précedente),

Tu en est sûr ? Le TILF le donne bien avec la signification
«@Produire (quelque chose) au terme d'un long labeur », avec
ensuite des restrictions ou aux domain de l'activité
physiologique ou que le complement désigne une oeuvre de
l'ésprit. En citant bien une utilisation chez Rabelais.

Tu me dirais que je suis mal placé pour dire, mais « élaborer
tes pensées » me semble tout à fait français. Et je ne dirais
jamais en anglais « elaborate your thoughts ».

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr wrote:

À part qu'élaborer est un anglicisme (ça c'est à propos d'une
discussion précedente),
Tu en est sûr ?

Oui et non.
Utilisé ainsi, c'est un anglicisme. Le mot « élaborer » existe. Mais on
ne l'utilise pas dans ce contexte.

«@Produire (quelque chose) au terme d'un long labeur », avec

C'est ça. Mais « can you elaborate ? » singifie (sauf erreur) en anglais
une demande de précision et se traduit volontier par « Peux-tu
développer ? » ou « Peux-tu préciser ta pensée ? ».

Tu me dirais que je suis mal placé pour dire, mais « élaborer
tes pensées » me semble tout à fait français.

Ben... Moi, je trouve pas. On élabore un projet ou un plan, mais pas des
pensées. Il y a vraiment l'idée de production, comme le dit ton
dictionnaire.

Et je ne dirais
jamais en anglais « elaborate your thoughts ».

Mais confirmes-tu que « Can you elaborate ? » se dit pour demander plus
de détails ou de précision ?

Arnaud

Dans le message 42e0ec7b$0$7657$626a14ce@news.free.fr,

kanze@gabi-soft.fr wrote:

À part qu'élaborer est un anglicisme (ça c'est à propos d'une
discussion précedente),
Tu en est sûr ?

Oui et non.
Utilisé ainsi, c'est un anglicisme. Le mot « élaborer » existe.
Mais on ne l'utilise pas dans ce contexte.

«@Produire (quelque chose) au terme d'un long labeur »,

C'est ça. On élabore quelque chose (c'est un verbe transitif).
Pour le reste, on peut facilement dire simplement « donner des
détails » par exemple...

C'est ça. Mais « can you elaborate ? » singifie (sauf erreur) en
anglais une demande de précision et se traduit volontier par «
Peux-tu développer ? » ou « Peux-tu préciser ta pensée ? ».

Juste une remarque : développer a aussi le défaut d'être un
anglicisme dans bien des contextes... dont celui classique qu'on
lui donne en informatique ! En principe, on ne peut pas parler
des étapes du développement d'un logiciel ou « développer » un
logiciel. Mais bonne nouvelle : il semble que c'est en voie de
devenir acceptable, en informatique seulement :-)

--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/