hello :) Fred :)
Je ne vais pas rentrer dans le débat.. Va voir : http://code.google.com/p/astuce/ <http://code.google.com/p/astuce/> Donc tu veux dire que c'est normal que Adobe n'a pas mi en place de tests unitaires pendant la construction du framework Flex et qu'il est tout à fait normal qu'il n'y en ait pas dans toutes les versions actuelles du framework ? Je comprends vraiment mal ta réaction ici ... et je me demande vraiment si l'on parle bien le même langage :) Pour moi c'est simple.. on peut faire le boulot de Adobe vu que le projet est opensource c'est clair mais à la base ils se doivent de faire leur boulot correctement... Flex n'a pas de test unitaire et pour moi c'est un frein pour la stabilité de n'importe quelle application basée sur le Flex SDK même si cette application est elle même unit testé... PS : pour moi développer sans test unitaires.. c'est pas "dommage" c'est surtout handicapant à un certain niveau et vu le nombre d'utilisateurs derrière.. Reste maintenant que tu nous fais un grand cours sur les units tests au dessus.. que tu dis que nos tests ne servent à rien et sont mal faits.. je suis certain du coup en lisant ton commentaire au dessus que tu as une maîtrise absolue pour créer du code et des projets opensources ... mieux que nous... donc c'est cool :) Tu es un géni et nous sommes des pauvres débiles ... En attendant j'adorerai voir tout ton joli travail opensource pour me faire une idée d'un code utilisant autant de grand principe que les tiens et qui je pense nous apprendra plein de belle chose pour nos développement futur :) Et je me demande du coup comment cela se fait que nos tests unitaires au niveau de Google ou Adobe semblent tout à fait convenir et qu'ils utilisent nos méthodes de travail au bout du compte sur un boulot commun ??? Putain !!! On a tout faux depuis le début alors .. merde alors :) Merci pour ton aide en tout cas :) eKA+ :) Le 29 janvier 2009 10:00, Fred NGUYEN <[email protected]> a écrit : > Heu... > Donc... > > Pour reprendre le principe du patch. > Évidemment qu'un patch sur quelque chose que tu ne maintiens pas n'a pas > une vocation à être pérenne. C'est la vie. Raison de plus pour ne pas > l'appliquer directement sur le framework, de pouvoir le voir distinctement, > pour le modifier / supprimer selon le cas. > L'ouverture de tickets peut fonctionner, et, remarque, cela ne coûte rien, > mais attendre que les gens bossant sur flex appliquent un correctif peut > être long, et donc non viable. Surtout dans ce genre de situation: > http://bugs.adobe.com/jira/browse/SDK-12259 . Je te laisse décripter > tranquillement le contenu de cette page. > > Maintenant, pour les unit tests, tests... > " ces 4 lignes me font dire que soit tu confonds "tests" et "unit tests" ou > soit tu ne sais pas ce que sont des unit tests" > La réponse à cette déclaration pourrait être "you made my day guy..." > Mais je vais tenter de prendre un peu plus de temps pour y répondre. > > Non, je ne confonds pas tests, et tests unitaires... Il n'y a pas de > confusion à faire, les tests unitaires sont des tests. > Le principe d'un test unitaire, à côté d'un test fonctionnel par exemple, > est de tester une unité de code la plus petite possible. En programmation > objet, l'unité sera donc la méthode. Que tu utilises ensuite FlexUnit pour > mettre en place tes tests unitaires ou non, tant que tu poses des tests > autour de l'unité, tu écris des tests unitaires. L'exemple que tu donnes me > laisse plus à penser que tu utilises FlexUnit, mais que tu ne comprends pas > encore totalement la notion de tests unitaires. > Par ailleurs, mettre autant d'assert dans un seul test souligne quelques > lacunes dans ta méthodologie de tests... Enfin, j'y arrive... > > Ne pas avoir les tests unitaires du framework flex... J'aurais tendance à > penser que c'est une fausse question de ta part. On peut imaginer assez > facilement, effectivement, qu'il n'existe que peu de tests couvrant le code > de Flex (que ce soit vrai ou faux.. après.. c'est encore un autre problème). > Si l'on part de cette idée-là, que tu sembles partager, la demande que tu > fais se positionne au mieux comme une boutade. Oui, c'est dommage qu'ils > n'en fournissent, d'un autre côté... > > D'un autre côté, pour reprendre ce que j'ai écris hier, un bon test > unitaire, contrairement à un bon test fonctionnel, doit être écrit par la > personne implémentant une fonctionnalité. Simplement par qu'il est le seul à > connaitre potentiellement le comportement à risque de son code. > > Maintenant, admettons que Flex soit bardé de tests unitaires, et que tu > sois face à un bug... Tu peux facilement imaginer que ce bug a échappé aux > tests. Tu le traques, et le trouves. Chic! Modifions le code, pour en > corriger son comportement!.Ce dernier propos implique que tu vas ajouter > "ton" code au framework déjà existant. Ce code, et comportement, n'aura > sûrement pas pu être pris en compte par les gars de Flex, et donc ne fais > pas parti des tests. Du coup, allons-y avec des pincettes... > On commencera alors par entourer le code à modifier de tests. On lance les > tests. On vérifie que, pour la portée, tous les tests sont bons. On modifie. > On relance les tests. > C'est la méthode la plus répandue lorsqu'on travaille avec du code > existant, et que l'on peut disposer d'un framework de tests unitaires. > A ce sujet, je pourrais te conseiller deux lectures qui me l'ont été assez > récemment: > Refactoring / Improving design of existing code , de Martin Fowler > accompagné par Kent Beck > et Working effectively with legacy code, de Michael Feathers. > > Maintenant, pour en revenir à l'intérêt et l'ecriture de tests unitaires... > Rapidement et succintement, car il y a beaucoup de choses à dire: > >> un unit test, ca passe ou ca ne passe pas, et cela permet justement >> de travailler a plusieurs sans casser le travail des autres >> > non > > de plus cela a aussi une valeur educative, qlqn qui n'est pas >> famillier avec un gros code source peut lire les unit tests en plus du >> code >> > pour mieux comprendre la logique et/ou le comportement et/ou les >> limitations etc. > > presque > > Un tests unitaire n'est pas là pour vérifier que tu ne casses pas le code > du voisin. LA vocation des tests unitaires est d'être rouge. Leur raison > d'être n'est pas d'assurer que tu ne casses rien. Leur raison d'être est de > diminuer, voir presqu'anéantir, la phase de débugage, que ce soit pendant > l'écriture de code, on pendant une session de refacto. C'est la raison pour > laquelle, au sein d'un seul test, on a une tendance à mettre le moins > possible d'assert. Pour une mêmee fonction, on aura plusieurs tests, de > manière à pouvoir isoler le plus rapidement possible l'assert qui aura > sauté. Si je reprends l'exemple de ton code, si les asserts #4, #7, #9, #11 > explosent pour des raisons différentes, combien de fois devras-tu relancer > ta phase de debug? A priori 4, vu que chaque assert ne passant pas masquera > les autres. Evidemment... J'imagine que le cas n'arrivera jamais... Mais > alors, pourquoi autant d'asserts? > > Pour ce qui est du rôle "éducatif", merci pour les étudiants ^^. Mais on > utilisera plutôt le terme de "documentation". > > Pour finir... Effectivement, développer sans tests unitaires est dommage, > ces derniers corrigeant nombre de soucis que le développement d'application > rencontraient. Ceci dit... Que cela soit ingérable, je ne pense pas non > plus, il ne faut pas déconner. L'industrie du logiciel produit depuis un peu > plus qu'une petite dizaine d'années. Que cela te soit ingérable pour ton > projet, reste quelque chose de totalement personnel. Par ailleurs, étant > donné que tes tests ne semblent pas pour le moment des mieux écrits, je ne > saurais que te conseiller de continuer à te former aux méthodes de > développement agile, avant de râler à tue-tête contre la le staff de Flex ;) > . > > Les deux bouquins cités plus haut sont trouvables tous les deux sur Amazon. > > > > > --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/FCNG?hl=fr -~----------~----~----~----~------~----~------~--~---
