> 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...
non il n'y a pas de lacunes
mais pour ca il faut lire et comprendre le test
ce n'est PAS important d'avoir un seul assert par methode de test
et ceci a été longuement débatu dans la communauté Java avec JUnit
dire qu'un test est mauvais ou a des lacunes simplement parce qu'il
a plusieurs asserts c'est une approche tres newbie des unit tests
donc je reprends l'exemple de tester un "toString"
tant qu'on test cette fonctionalité, qu'il y ait 1, 2, 10 asserts
tant que ca focus seulement sur cette fonctionalité, c'est ok
ce qui serais mauvais se serait de combiner plusieurs asserts
qui testeraient plusieurs fonctionalités dans une seule methode de
test
voir http://www.exubero.com/junit/antipatterns.html#Multiple_Assertions
"This particular aphorism in the FAQ has caused a large amount of
discussion. The best advice is that it's not important to have
precisely one assert per test; many experienced testers have multiple
assertions in a block at the end of a test method. However, it is
generally a bad idea to intermix code that exercises functionality
with code that asserts expected results. This means that the cause of
failures can be very hard to track down."
> 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.
bah voyons, oui forcément c'est mieux que le dev qui implémente du
code
écrive les unit tests qui vont avec, mais ca ne veut pas dire que
uniquement
ce dev puisse modifier/ajouter/etc. le code et/ou les tests
quand on est dans une logique de "personne ne control/possede un code
en particulier"
(no code ownership)
voir http://www.artima.com/intv/principles4.html
"Martin Fowler: The way I look at it, there are three styles of code
ownership. There is the XP style, which is sometimes referred to as no
code ownership and sometimes as collective code ownership. In this
style, no code is assigned to any particular person on the team.
Anybody on the team can change any part of the system at any time.
That's the XP approach."
c'est pas des bouqins mais ce genre de discussion ca aide aussi à
éduquer
> 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.
tu dis ca avec la logique qu'une seule personne puisse modifier tel
code
et/ou unit test lié a ce code
moi, enfin nous, on est dans une logique que plusieurs personnes
peuvent
travailler sur le meme code, donc pour une classe X personnes peuvent
travailler dessus
de plus meme si les tests sont fait dans une logique d'isolation,
il y a toujours des cas où une classe aura des dépendances sur
d'autres classes
si j'ai une classe Char qui dépends d'une autre classes Unicode etc.
si je modifie la classe Unicode il se peut que ca casse le
fonctionnement
de la classe Char
a nouveau l'argument des plusieurs asserts, désolé mais ca tient pas
la route
> 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 chaque assert tu peux avoir un message text qui permet de pointer
sur le bon assert directement
et à nouveau si tu concentre les différents asserts sur une et une
seule
fonctionalité, cela permet de savoir si cette fonctionalité est
completement gérée ou pas
re-ex du test du toString( 1 arg ici )
c'est important de pouvoir tester dans la meme methode de test
les variations de cet argument
faire plusieurs methodes de tests juste pour la variation de
l'argument
c'est possible oui mais ca duplique pour rien les metodes de test
> 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.
non je déconne pas, quand une base de code atteinds un certain volume
le manque ou le trop peu d'unit tests freinera de beaucoup, voir
empechera,
de modifier ce volume de code
sans unit tests un gros volume de code
- est moins stable
- a une qualité de code tres bas
- est tres difficilement updatable
- est tres tres tres difficelement modifiable par plusieurs personnes
- est encore plus difficile pour intégrer de nouvelles personnes
etc.
ingérable ne veut pas dire impossible, ca veut juste dire ingérable
gestion d'un volume de code
- qualité
- stabilité
- maitrise des bugs
- travaille en équipe
etc.
> L'industrie du logiciel produit depuis un peu
> plus qu'une petite dizaine d'années.
oui juste un peu plus, essaye plutot uen bonne 40aine d'années
http://en.wikipedia.org/wiki/Software_company
"The software industry started in the early 1960s"
> 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 ;)
je parle de projets conséquents, mais n'importe quel type de projets
pure AS3, Flex, mixte, open soure ou pas, etc.
pas d'unit tests == projet qui devient ingérable à terme
et ce de manière donc générale
si les unit tests et TDD viennent de XP
le fait que un mouvement général dans les différentes communautés de
devs
utilisent de plus en plus les unit tests depuis ces dernières annés
sans forcément utiliser la méthodlogie XP
cela prouve amha que les unit tests sont un composant qui permet
de mieux gérer le code
pour ma formation aux methodes agiles
j'ai travaillé en mode agile avec Adobe Consulting
sur un projet Flex constitué d'une équipe de 30 devs
en fait ce projet était et est toujours le plus gros projet Flex en
europe
donc j'attends pas vraiment apres toi pour faire du agile
franchement le ton "donneur de lecon" c'est ca qui nous fait dire que
tu troll
> Je ne publierai pas mon code, mon employeur (Ankama) risquerait de ne pas
> l'apprécier.
donc, je resume, on part d'un thread qui parle du Flex SDK comme
projet open source
tu t'amenes et tu dis que on fait mal nos unit tests sur nos projets
open source
mais tu n'as pas une seule ligne de code open source que tu peux
montrer
> Ce genre de propos montre qu'effectivement tu ne souhaites pas entrer dans
> la discussion. Concernant les méthodes, il y a beaucoup à apprendre, et à
> discuter, et je dis cela pour moi tout comme pour vous. Je tentais de donner
> un avis un minimum construit, et je me prends un troll en retour.
j'ai pas vu tes propos comme un "avis que tu donnes" mais plutot comme
un ton condescendant du genre "mon petit je vais t'apprendre les unit
tests"
ca fait tres troll quand meme
> Si tu souhaites rester sur une position de refus total de toute critique, je
> ne m'en formaliserais pas non plus, et, après tout, je peux comprendre assez
> facilement qu'on puisse ne pas aimer se faire reprendre.
quand tu dis que c'est comme ca qu'il faut ecrire un unit test
tu vas un peu plus loin que la critique
basiquement on s'en fout royalement du ton paternel,
blah blah je te reprends mon petit, tes unit tests sont mauvais, blah
blah
perso je vois ca comme une blague de troll
je commente principalement parce que je ne veux pas
que qlqn qui lirait ce thread se dise
"a merde j'utilise plus de 1 assert dans mes unit tests, ouhlala c'est
pas bien"
non, c'est faux
et oui on a plein de projet open source qu'ils soient persos
ou plus officiel comme gaforflash
qui non seulement montre l'usage de ces unit tests
et oui utilisent plusieurs asserts par methode de test
bref, du concret
pour le reste, voir ce qui dit Eka
zwetan
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
