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 -~----------~----~----~----~------~----~------~--~---
