Discussion :

[vertebre]

Bonsoir,

Dans le cadre de projets qui aboutissent bientôt (enfin je l'espère), j'en viens à me documenter sur les optimisations et les tests à faire sur son code.

Je me suis documenté sur les tests unitaires (dans mon cas avec Jasmine/Karma pour une application Angular) mais je ne saisis pas l’intérêt de ces tests, ou plutôt l'envergure de l'utilité.

J'ai retenu 2 choses utiles :

• vérifier le types des paramètres passées au fonctions par rapport à ceux qu'elles attendent
• vérifier que les fonctions remplissent bien le travail qu'on leur a demandé

Ce que je ne saisis pas c'est que tester le type des paramètres d'une fonction pour verifier qu'ils soient du type attendu c'est bien, mais si ce n'est que lors des tests quels intérêts y a t il ?
Enfin, si je tente d'appliquer ces vérifications de types de paramètres à toutes mes fonctions, cela va surement surcharger la vitesse d'exécution elle même, non ?

De plus, tester si une fonction fait bien son travail, je ne comprend pas l'utilité étant donné qu'on a crée cette fonction spécifiquement pour faire qqch, alors à quoi bon la tester si après création de la fonction et debug, elle fait son travail ?

désolé de ma faible expérience, mais je tourne en rond vous voyez ...

[dourouc05]

De manière générale, les tests servent à s'assurer que les fonctions restent correctes pendant toute la durée de vie du projet. Petit exemple : tu codes une fonction, qui fait exactement ce que tu lui demandes pour tous les cas utiles. Six mois plus tard, tu fais quelque chose de très proche et décides d'ajouter un paramètre à cette fonction : les tests serviront à s'assurer que la fonction continue de donner les bons résultats pour les premiers cas d'utilisation. Pire encore : trois ans après, tu décides de refactoriser une partie, les tests s'assureront que tu as toujours bien les résultats voulus.

Aussi, en écrivant des tests, tu réfléchis encore une fois à ton code, tu trouveras peut-être des chemins d'exécution que tu n'avais pas prévus à l'origine et qui ne fonctionnent pas, alors qu'il n'est pas impossible qu'ils soient utilisés dans l'application (mais moins fréquemment).

[vertebre]

merci pour cette explication.

sinon, est ce que ces tests peuvent être employés pour mesurer la qualité du code ou de son efficience ?
je pense bien que non mais dans ce cas quels types de tests le permettent ?

[Marco46]

sinon, est ce que ces tests peuvent être employés pour mesurer la qualité du code ou de son efficience ?

Non ça sert à mesurer que le code fait ce qu'il est censé faire.

Donc à chaque itération d'évolutions / fix ça permet en appuyant simplement sur un bouton d'avoir en bout de ligne un indicateur OK / KO.

C'est absolument in-dis-pen-sable dans le cadre d'un développement en mode agile où l'on est sans arrêts entrain de refactorer l'existant.

Si en soi les tests ne permettent pas de déterminer la qualité d'un code ou son efficience (qu'entends-tu par efficience d'ailleurs ?), le taux de couverture (même s'il peut être simulé) est généralement un bon indicateur de la qualité d'un livrable. En ce qui me concerne et en tant que tech lead je considère un code non testé comme non livré. Et je rejette les merge request sans tests unitaires associés.

je pense bien que non mais dans ce cas quels types de tests le permettent ?

C'est plus le rôle des linters de check la qualité du code. Cf Sonar ou ESLint.

[vertebre]

merci également pour ton explication,

qu'entends-tu par efficience d'ailleurs ?

Pour un pécheur qui doit pécher des poissons, il peut faire çà à la main ou avec une canne à pêche, la cane à pêche est la solution la plus efficiente.
Dans le cadre d'une fonction, j’entends par là les moyens utilisées pour coder le traitement que la fonction doit faire, par exemple le fait d'utiliser des Map<> plutôt que des tableaux.

Mais effectivement je cherchai une analyse plus approfondie en ce qui concerne l'efficience du code, et je vais essayer sonar qui me semble être un bon outil

Qu'est ce que le taux de couverture ?

[Marco46]

Si tu fais du javascript le must reste ESLint.

[vertebre]

ok merci bien

[yildiz-online]

Pour un pécheur qui doit pécher des poissons, il peut faire çà à la main ou avec une canne à pêche, la cane à pêche est la solution la plus efficiente.

Pour des poissons piégés dans un trou d'eau à marée basse, la méthode à la main sera plus efficiente, ce qu'il faut en retenir, c'est que le contexte prime sur la méthode, il n'y a pas de généralité imparable.

Il en va de même pour le code.

[el_slapper]

Pour des poissons piégés dans un trou d'eau à marée basse, la méthode à la main sera plus efficiente, ce qu'il faut en retenir, c'est que le contexte prime sur la méthode, il n'y a pas de généralité imparable.

Il en va de même pour le code.

Celle-là, je me la garde. Elle est magnifique. Dommage qu'il ne reste plus de place dans ma signature.....

[slim]

De manière générale, les tests servent à s'assurer que les fonctions restent correctes pendant toute la durée de vie du projet. Petit exemple : tu codes une fonction, qui fait exactement ce que tu lui demandes pour tous les cas utiles. Six mois plus tard, tu fais quelque chose de très proche et décides d'ajouter un paramètre à cette fonction : les tests serviront à s'assurer que la fonction continue de donner les bons résultats pour les premiers cas d'utilisation. Pire encore : trois ans après, tu décides de refactoriser une partie, les tests s'assureront que tu as toujours bien les résultats voulus.

C'est surtout que si tu quittes le projet et que tu es remplacé par quelqu'un d'autre qui ne connait pas le code de l'application, les tests lui permettrons de refactorer plus facilement
et il ne faut pas oublier qu'il faut toujours se dire que le développeur qui te remplace est un fou furieux et qui sait ou tu habites :-)