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