Je te remercie pour ta réponse, je vais lire ce petit lien. Cedric
> Je n'ai compris tout de suite de quoi tu parlais, Cédric, en > disant : "car en les enlevant, > tout partirait dans les choux". Après avoir cliquer sur ton lien, > j'imagine que tu as confondu un "assert" présent dans un test > unitaire, et un assert de code de production. > Un assert de production permet de tester autre chose qu'un test > unitaire, et est notamment pratique lorsque tu n'as pas > d'informations claires sur le système entrant de ta méthode > (arguments ou autres). De manière grossière, ce genre d'assert > correspond à un if (...) throw ... > > Je pense, peut-^^etre à tord, que la méthode de développement peut, > et doit etre abordé en conservant une abstraction par rapport au > code. Parce qu'il ne s'agit pas d'écrire du code, en réalité. Il > s'agit de satisfaire plus facilement un client donné, de réduire > l'effort de développement et les risques. > > Pour continuer avec un autre lien : http://xunitpatterns.com/Goals% > 20of%20Test%20Automation.html > Je trouve cette article vraiment bien, par sa teneur générale, et > le niveau de vulgarisation qu'arrive à maintenir son auteur. > > On y retrouve une partie de ce que dit Joel, (et au final, de ce > que beaucoup disent) à propos de la manière dont on peut poser les > tests. Mais surtout, il essaye d'y mettre en exergue le role de ces > dits tests automatisés. > > Un point qui m'y semble relativement important, est le passage sur > le risque de surcharge d'effort de développement. Les tests > automatisés s'intéressant aux unités de code permettent de réduire > le stress portant sur la conception, d'aller plus vite vers une > première intération utilisable, et réduire le temps de recherche de > bugs (qui était, auparavant, une grosse bete noire). > > Ceci dit, il peut y avoir un revers à cela. En voulant mettre trop > de tests, un refactoring d'une portion de code peut engendrer la > maintenance d'autant de tests. En ayant trop d'asserts [de tests] > pour une meme fonctionnalité, on engendre également une maintenance > plus importante. Le temps et l'effort gagné sur le développement, > la conception et le debug se retrouvent alors remplacés, voir pire > dépassés, par le temps utilisé à remettre en ordre ses tests, sans > compter le risque d'en louper au passage. On y perd du coup une > partie importante de l'intéret des tests unitaires. > > Quoiqu'il en soit, l'article de xunitpatterns est vraiment un > document assez complet, et simple à lire, sur le sujet, bien que > "codeless". Mais, parfois, avant de la pratique, un peu de théorie > pour comprendre pourquoi on utilise plutot telle ou telle méthode > ne me semble pas superflu. > > Désolé si cela fait cour de récré... Ce n'en est vraiment pas le > but... > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
