Validation des paramètres d'une fonction

[simon_renoult]

Bonjour à tous,

Question que je me pose fréquemment mais concernant laquelle je n’ai jamais eu de réponse définitive, faute d’argument probant.

Qu’en pensez-vous, doit-on systématiquement tester les paramètres d’une fonction ?

• Si oui, que tester ? Nullité ? Type (je pense notamment à JavaScript qui n’est pas typé) ? Validité fonctionnelle ?
• Si non, c’est prendre le risque de faire confiance au contrat d’interface proposé par la méthode, fausse bonne idée ?

Je suis personnellement plus en faveur du test exhaustif (aka paranoïa) : nullité + type (via https://www.npmjs.com/package/is par exemple) + validité fonctionnelle et tout ça avec les tests unitaire qui vont bien. Mais ça pose la question de l’intérêt de l’utilisation de JavaScript, qui par design n’est pas typé or ici je recrée un système de type. Fausse bonne idée ?

[lkdjiin]

Ça va surtout dépendre du type de l’application. Coder l’allumage d’un réacteur nucléaire n’aura pas les mêmes implications que coder une interface web. Comme tu parles de javascript, j’imagine qu’on est plutôt dans le second cas et que la programmation défensive est sûrement overkill.

[abelar_s]

C’est bien de concevoir des systèmes en isolation mais on ne peut pas non plus avoir peur de son ombre : ces tests coûtent en perf et surtout… une fois que ça pète tu en fais quoi ?
Soit ton archi est prévue pour remonter ces erreurs et faire du graceful recovery (rare, cher, complexe et presque toujours à faire au cas par cas) soit… tu as fait un test dans ta fonction pour que la fonction crash pas mais l’appli crash car la fonction appelante n’a pas eu son retour attendu !

Au final, le souci n’est pas de faire des préconditions/postconditions dans tes fonctions mais d’avoir une confiance pour avancer. Typiquement les Haskellers sont contents par nature, les C++ers par le compilo, les rubyistes par les tests, bref dans ta stack mais pas dans le code de prod.

En plus c’est dommage d’utiliser un langage dynamique pour le brider.
C’est le Zen of Duck Typing : https://duckduckgo.com/?q=the+zen+of+duck+typing&t=ffab
(tiens, l’archive ML de Nagaoka UT semble down ? dommage c’est culte ce post)

J’ai beaucoup suivi les innovations de types et autres annotations ou contrats dans les langages dynamiques, et certaines des directions les plus intéressantes tentaient vérifier ton code dans le cadre d’une moulinette de test, à grand coût de perf (sondage, fuzzing, preuves formelles) et que tu désactives ensuite en prod.
J’imagine que les langages qui font ça (Eiffel/Coq) doivent utiliser le même genre d’astuces.

J’ai trouvé ça malin et je rêve, comme les tests et vérifications sont différents selon que tu parles d’une bibliothèque ou d’une partie de ton appli moins “à externaliser”, que les libs fournissent des sortes de contrats d’interface et que chaque dev puisse alors vérifier via ses tests que sa lib est bonne (testée en interne), son code est bon (il le teste aussi) et l’utilisation de la lib respecte les contrats fournis par la lib (ça manque un peu mais il faudrait changer notre manière de coder pour ça).

Je n’ai pas lu mais il y a des gens qui ont parlé de cette “confiance” dans Confident Ruby et le livre a de très bonnes critiques. La communauté Node finira bien par avoir des auteurs et moult livres aussi j’imagine :)
++