Bonjour,

Utilisez vous des tests unitaires lors de vos développement ? Je ne le fait pas personnellement, et je n'arrive pas à comprendre l'interêt d'en faire, j'ai l'impression que c'est plus une perte de temps qu'autre chose.

Dans quelle situation cela peut vous être utile ?

Petite question: comment t'assures-tu , aujourd'hui, du bon fonctionnement de ton code ?

Salut,

je suis extrêmement rigoureux sur ce que je développe, notamment j'utilise énormément les typage pour m'assurer que la donnée est bonne. Aussi je blinde mes formulaires donc on ne peut pas valider ce que l'on souhaite.

Après j'ai pas de cas concret d'applications autre que du formulaire / requête SQL, donc pas d'autre idée de ce qui pourrait être fâcheux dans mes applications.

Bonjour,

On teste pour s'assurer que le système de validation des données mis en place par les programmeurs sont efficaces en utilisant plusieurs jeux d'essais différents qui couvrent tous les cas possibles. Ainsi, certains bugs peuvent être décelé et corrigé avant le recettage. Car on ne peut pas prétendre qu'un système de validation de données programmé est blindé sans le mettre à l'épreuve par rapport aux conditions particulières d'exécution à laquelle il est destiné.

Salut,

je suis extrêmement rigoureux sur ce que je développe, notamment j'utilise énormément les typage pour m'assurer que la donnée est bonne. Aussi je blinde mes formulaires donc on ne peut pas valider ce que l'on souhaite.

Après j'ai pas de cas concret d'applications autre que du formulaire / requête SQL, donc pas d'autre idée de ce qui pourrait être fâcheux dans mes applications.

Donc en gros tu testes pas tes applis car tu pars du principe que tu as effectué toutes les vérifications possibles et inimaginables ?
Gaffe à la boulette...

Comme dit sadeq, ça ne sert pas à valider les données entrantes, mais à vérifier que le code lui-même fonctionne comme il se doit.

D'ailleurs, tu as beau être aussi rigoureux que humainement possible, des erreurs tu en commettras. Parfois subtiles, parfois au plus mauvais moment (genre, dans le stress, quelques minutes avant une échéance cruciale).

Et en parlant de perte de temps, si tu modifies le code d'un des formulaires (une fonction de validation, par ex.), comment contrôles-tu le bon fonctionnement du formulaire ? Manuellement, en le remplissant de données bidons et en envoyant le tout ? Ca peut sembler rapide, mais fais-le une dizaine de fois par jour, et tu verras qu'on perd un max de temps à ne pas utiliser de simples outils de tests automatisés.

Les tests unitaires répondent simplement au besoin que, si une tâche est répétitive, elle doit être automatisée.

Par ailleurs, en se forçant a coder de façon a pouvoir utiliser des tests unitaires, la qualité du code s'en retrouve considérablement améliorée, puisqu'on est forcés à écrire des modules configurables, et donc bien plus réutilisables et flexibles.

Je sais que l'erreur est humaine, j'en ai faite, j'en fait et j'en ferai encore, c'est certain et acquis.

Maintenant, et surtout d'après le peu de chose que j'ai vu sur le sujet, je n'arrive pas à savoir comment l'utiliser, à quel moment, pour quels genre de tests.

J'ai une certaine expérience personnelle, et je n'ai pas eu la chance d'entrer dans une boite avec des dév expérimenté et/ou senior en entreprise, à vrai dire nous sommes deux développeurs, et le deuxième n'a ni d'experience pro, ni perso ( voir sujet sur le forum : emploi-etudes/bosser-avec-une-equipe-br ... 59276.html ).

Du coup, je reste convaincu que les tests unitaire sont une bonne chose, sans même savoir ce que c'est, mais je n'arrive pas à déterminer à quel moment les utilisé et pour faire quoi ... et surtout sans exemple concret et fonctionnel sur une vrai application.

Moi j'ai regardé les outils, ça ne m'a pas inspiré beaucoup. Mais sur le principe, tout à fait normal. D'ailleurs j'ai déjà utilisé Samurai (le framework), qui teste pas mal de failles possibles et d'exploit sur ton site ... Le test unitaire me semble un peu comme ça, c'est en gros, faire tout et n'importe quoi sur ton site pour voir comment il va réagir.

Après, il y a aussi un autre test important, c'est celui de "l'utilisateur est toujours un con". Lol developpez.com, merci ... Bref, tester avec des gens sans aucune connaissance s'il arrive bien à naviguer sur le site, à remplir les formulaires, etc ... Et des fois, toi, tu as essayé de craquer ton propre formulaire, et ce sont en fait ces gens-là, avec des actions légitimes d'utilisation, qui vont, par leur incompétence totale, te foutre une valeur complétement inattendue en base de données ...

En gros, j'ai pas la solution, car je viens de finir un CDD d'un an dans une boite où moi, stagiaire, était le plus expérimenté dans ce domaine, et que je n'ai pas eu les moyens de bosser. Je n'ai pas fait de coup de gueule sur le forum, j'ai attendu sagement la fin de l'année pour avoir mon BAC+2 et ... J'avance.

Il y a deux ans, j'étais un grand fan des test unitaires, j'ai même essayé de faire en sorte de couvrir à 100% un logiciel. Au début, ca marche plutôt pas mal, on est bien content de découvrir parfois des erreurs (en général mineur) rien qu'en réfléchissant au test ou en les faisant tournée.

Et puis peu à peu, j'ai découvert un problème : les test rendent les programmes ... "collant". C'est à dire que, lorsque l'on a bien fait un test sur une classe et que viens le moment de refactoriser cette classe, on va beaucoup hésiter à faire plusieurs opération nécessaire au refactoring comme : découper une classe en deux, redécouper les fonctions d'une classe de manière plus propre, fusionner des classes, modifier la construction de l'objet, ... Dans tous ces cas, cela demande en plus du refactoring, de bien souvent devoir se retaper le développement de tous les tests ... J'ai donc alors découvert que les tests sont très très loin d'être gratuit et font chuter la performance du développeur, ou bien pire, peuvent arrêter ou freiner les effort de refactoring.

J'ai donc complétement changé mon fusils d'épaule : je ne fais plus guère de test unitaire et si j'en ressens le besoin, c'est que mon code doit certainement être trop compliqué et à besoin d'un bon refactoring.
Les seuls endroits ou j'en utilise encore, c'est lorsque un algorithme est particulièrement complexe, mais cela reste extrêmement limité et existe très marginalement en informatique de gestion.

Donc, les tests unitaires, c'est comme les commentaires : moins il y en a, mieux je me porte

Donc, les tests unitaires, c'est comme les commentaires : moins il y en a, mieux je me porte

Mais qu'est-ce qu'il ne faut pas entendre ...

Dans un développement object, ton code se repose sur une couche métier généralement importante, qui contient toutes les règles ... métiers (ça ne s'invente pas ^^) de ton site.
Au final, les interfaces ne font que mettre en oeuvre cette couche métiers, et transformer les données brutes en affichage. Une méthode d'une couche métier est donc potentiellement utilisée à X endroits.
De plus, une couche métier bien développée est organisée, en plusieurs couche (héritage), dont chaque méthode a une signature et un fonctionnement propre.

Au final, le changement d'une pauvre petite méthode peut avoir des impacts en chaîne.

Le but du test unitaire est à la fois de tester automatiquement que ce pour quoi tu as codé une méthode est toujours assuré, et elle permet de la documenter (bah oui, les tests permettent de comprendre ce pourquoi une méthode a été développée).
Ainsi, quand tu modifies quelque chose, il suffit de relancer les tests unitaires pour savoir si tu as cassé quelque chose, sans passer à chaque fois sur l'intégralité de tes interfaces.

Maintenant, plusieurs choses à comprendre sur les tests : un code testé à 100% n'est pas un code dont les tests passent sur 100% des lignes (couverture de code), mais un code dont tout les cas d'utilisations sont testé. Et ça, c'est tout simplement impossible.
Quand on rédige des tests, on écrit les cas pour lesquels on a prévu une méthode. Au début, c'est du temps perdu (avant d'écrire les tests, tu as essayé ton code, donc tu sais qu'il marche), mais quand ton application dépasse le 10 classes et/ou les 2 mois de développements, toute petite modification est plus simple puisque tu ne commences pas par perdre 1h à savoir où est utilisée une méthode, pour quels cas de figure, en passant obligatoirement à côté de quelque chose.

De plus, le test unitaire aide le refactoring, puisque tu peux réécrire une méthode, la découper, il n'y a que les tests unitaire de CETTE méthode à réécrire, ceux du dessous DOIVENT continuer à fonctionner. Sinon, cela signifie que tu as cassé quelque chose.

Au final, les tests unitaires sont là pour documenter et tester les cas d'utilisation de tes méthodes pour garantir une non-regression (tu n'as pas cassé quelque chose qui marchait) d'un code.
C'est un coût plus important au début pour un gain à très court terme.

Maintenant, epommate2, par curiosité, j'aimerais savoir dans quel cadre tu développes, pour quels types d'applications, parce que plus je te lis, plus je suis effrayé par tes réponses, et le ton absolu que tu leur donnes
Ne pas mettre de commentaires, ou comment ne pas se rappeler ce qu'on a fait il y a plus d'un mois (si on travaille seul) ou ne jamais comprendre ce qu'a fait un autre (si on travaille en équipe).
Je te concède qu'un code bien écrit se lit, mais il y a TOUJOURS un moment où le code est nécessaire (pourquoi tel test, pourquoi telle boucle) et les phpdocs devraient devenir une habitude.

Bon, maintenant qu'on à un peu élagué le sujet, je peut y mettre mon expérience aussi, qui se situe quelque part entre Zeus et epommate2.

D'abor, le souci d'approche d'AoSiX. Je te conseillerais de t'y essayer à l'occasion d'un petit projet, une petit appli qu'on te demande, sans grande envergure. Perso, c'est lors d'un petit truc en Python que je m'y suis mis, carrément du Test-Driven (je me suis aidé de Test-Driven Development de Kent Beck). C'était très agréable, on ne progresse pas très vite, mais la boucle du "J'écris un test - je constate qu'il échoue - j'écris le code qui valide le test - je constate qu'il fonctionne" est assez stimulante une fois qu'on est pris dedans. Et quand vient le moment de lancer le script, tout fonctionne à merveille. C'est bien plus rapide de lancer une batterie de tests que d'exécuter à chaque fois l'application, et autant pour la conception que pour le débugage, les tests unitaires procurent beaucoup d'assurance et de célérité.

Même qu'après ce petit projet, je ne pouvais plus rien coder sans m'assurer que le code fonctionne, c'était à en avoir le vertige. En revenant à du code sans tests, je me sentais en totale insécurité: rien n'était garanti, la stabilité n'était pas assurée, c'était passer d'une structure en béton armé à un château de cartes. Et donc j'ai commencé a faire des tests dans chaque environnement (Perl, Php, Js, Erlang - j'ai même cherché pour bash), puisque je n'arrivais plus à avoir confiance dans ce que j'écrivais. Ou en tout cas, j'avais besoin de ce sentiment de totale tranquillité que procurent les tests unitaires.

Maintenant, de l'eau a passé sous les ponts, et je n'écris plus que des tests pour les fonctions les plus élémentaires, les plus utilisées à travers l'application. Pourquoi ? Parce qu'elles sont cruciales, souvent assez complexes, et qu'elles changent très peu. Et si elles changent, je dois être sur qu'elles fonctionnent comme avant, dans tous les cas. Les fondations quoi. Pour le reste, le code qui s'occupe de l'affichage, du comportement etc.., c'est du code qui change souvent, je fais évoluer le nom des méthodes et des variables, du refactoring constant, organique. Il serait vachement contraignant d'adapter à chaque fois tous les tests. Mais j'ai tiré mes leçons des tests unitaires, qui ont forcés quelques pratiques qui sont restés. Le code est plus propre, granulaire, modulaire, configurable.

En étant passé par la, c'est certainement un bagage a avoir. A chacun d'en faire son usage.


PS: je suis un développeur assez solitaire, mes collègues qui développent en sont encore à VB3 (ils progressent vers le 6 - vive le public!), et je doute qu'ils aient un jour entendu parler de tests unitaires. Dans le cadre d'un développement en équipe, je ne peux donc dire l'apport des tests unitaires, mais j'imagine qu'il est décuplé. Pour un retour d'expérience impressionnant, IMVU, le machin jeu-social-manga-messagerie-instantanée-3D, fait 50 mises à jour par jour. Un développeur peut apporter une modification, et si les tests passent, c'est immédiatement mis en production. C'est assez édifiant:
http://timothyfitz.wordpress.com/2009/0 ... mes-a-day/

ok, quand je me un smiley, c'est qu'il ne faut pas forcément prendre au pied de la lettre ce qui est avant

Bien sur qu'il existe des cas ou le test unitaire est nécessaire, par exemple sur un jeu de poker que j'ai eu à développer, je n'imagine pas que l'algorithme qui calcule
la comparaison de deux mains puissent être fait sans test unitaire. Toutefois, je considère que ce n'est pas une bonne pratique de systématiser ces tests car il ont un prix (que j'essaye d'expliquer dans mon premier post).

Pour ta question, je développe principalement des applications de gestion, des jeux par navigateur et des utilitaires web.

En ce qui concerne les commentaires, ce n'est peut être pas le bon fil ?

C'est un coût plus important au début pour un gain à très court terme

a long terme, je dirais ...

Pour ma part, je ne commente quasiment jamais, mais je ne suis largement pas un modèle là-dessus. J'ai presque envie de me fouetter en me disant "C'est mal, paf !".

Pour les tests unitaires, je n'ai aucune expérience là-dessus, je teste régulièrement à chaque fois que le code évolue, à la mimine. J'ai plein de choses à voir, même des choses bien élémentaires, et - on va dire - là où j'ai une excuse, c'est que, malgré que je n'ai pas un mauvais niveau, je suis totalement conscient qu'il me reste plein de choses à apprendre. Malheureusement, pour mon diplome, cette année, j'ai passé plus de temps, en alternance, à faire de la vente et des flyers, que du code. Mon évolution vient surtout du travail le soir à la maison quand j'ai le courage.

C'est pourquoi, quand j'ai vu la première fois "tests unitaires", j'ai regardé un peu le principe, et je me suis dit qu'il faudra que je voie ça, parce que, je résonne en toute humilité par rapport à mon statut de développeur professionnel. Il faut le dire : professionnel, mais avec beaucoup de connaissances et d'expériences à acquérir. C'est d'ailleurs pas si mal ... Je risquerais de m'ennuyer sinon

ok, quand je me un smiley, c'est qu'il ne faut pas forcément prendre au pied de la lettre ce qui est avant

Ok mais la tu mets un smiley donc doit on ne pas prendre au pied de la lettre quand tu dis que faut pas forcément prendre au pied de la lettre?
...
ou pas?

Ok mais la tu mets un smiley donc doit on ne pas prendre au pied de la lettre quand tu dis que faut pas forcément prendre au pied de la lettre?

Exactement, ca fait plaisir de voir qu'il y en a qui suivent !

http://fr.wikipedia.org/wiki/Paradoxe_du_barbier