Ce weekend, j'ai pu lire sur le blog de Roy Osherove la possibilité de "mock" les méthodes static via un mécanisme de swap... Ce support concerne évidement TypeMock. J'esperais pouvoir rapidement lire une réponse sur le blog d'Ayende suite à ce post ... Et en effet ... une réaction pour Rhino Mocks ^_^. Mais ce qui est réellement intéressant est de comprendre si il est intéressant de pouvoir mock les méthodes static et surtout si c'est un bon design ... A mes yeux, l'utilisation des méthodes static est tout ce qu'il ne faut pas faire :). Il faut minimiser l'utilisation de ce mot clé. Mais vous ? Qu'en pensez-vous ? Votre avis m'intéresse :-)
Voici quelques liens pour alimenter le débat:
Mock des méthodes static ?
mardi, mai 20 2008. Lien permanent General
3 réactions
1 De Steve Degosserie - 21/05/2008, 09:09
Pourquoi, à tes yeux, "l'utilisation des méthodes static est tout ce qu'il ne faut pas faire ?"
-> Quels sont tes arguments qui te font penser qu'il ne faut jamais utiliser le mot-clé static? ;o)
J'ai toujours un peu peur des "Silver Bullet" : il faut toujours faire comme ci, ne jamais faire comme ça. Si le mot-clé static existe, c'est qu'il a une utilité, que ce soit pour les membres d'une classe, ou pour les classes elles-mêmes. Il faut juste connaître les limitations et risques liés à celui-ci, et l'utiliser en connaissance de cause. => Il faut toujours regarder le contexte d'utilisation.
Personnellement, le mocking de classes ou de méthodes statiques, je ne trouve pas ça top ... ça sent le bricolage à plein nez. Au pire, cela doit intervenir dans un cas où l'on a pas les sources du code à tester et que l'on doit absolument écrire des tests unitaires d'intégration avec le système / la lib externe.
Si on a la maîtrise du code à tester, il a tjs moyen de faire une API propre qui prend en compte le cas du unit testing (méthodes internal qui te permettent d'injecter des stubs / mocks / fakes, et marquage de ta lib avec InternalsVisibleTo pour l'assembly contenant les unit tests).
2 De Thierry Thoua - 21/05/2008, 19:25
Pour moi, les static sont ce qu'il ne faut pas faire ... parce que ca nuit à l'évolutivité du code (je vise les méthodes static .... pas les champs static ...) ... Apres, les helper peuvent être sous forme static ou le pattern singleton ... Mais par exemple, pour moi ... une classe d'accès aux données en DB n'est JAMAIS static .. ;-). Ceci n'engage évidement que moi. Après, il y a la problématique du mock ... En effet, j'aime pas trop ce concept de mock de static ... mais je dois reconnaître que ce "patch" est intéressant. Beaucoup de projets ont des méthodes static.
3 De Pierre-Emmanuel Dautreppe - 25/05/2008, 13:22
Deux débats en un.
Je ne réagirais ici que sur l'utilisation (ou non) des méthodes static et des classes utilitaires.
J'ai eu ce même débat avec Laurent Bossavit, un coach XP. Les classes statiques et le pattern singleton sont probablement les plus mal utilisés : utilisation d'un singleton histoire d'avoir une instance unique alors que l'on ne devrait pas avoir d'instances, ou en avoir plusieurs, et utilisation de classes statiques comme remplacement des méthodes gloables, autrement dit un fourre-tout pour tout ce dont on ne sait déterminer réellement la responsabilité.
Faut-il être contre l'une ou l'autre approche ? Je rejoindrais Steve en disant que c'est effectivement au cas par cas. En se demandant à chaque implémentation le nombre d'instances dont on a besoin pour le développement.
Tu peux aussi aller jeter un oeil sur "blogs.msdn.com/scottdensm... (Singletons are Evil)
Pour ce qui est de l'évolutivité du code, entre intervenir partout dans le code pour changer des "MyStaticClass.DoSomething" ou des "MySingletonClass.Instance.DoSomething", comme dirait un collègue "c'est kif". Evidemment on arrive dans le débat "comment utiliser une classe singleton de façon à exposer son comportement et non le fait que ce soit un singleton"
Je n'ai en fait aucune position tranchée sur le sujet, si ce n'est le comptage d'instance nécessaire.
Pour ce qui est du mocks, je suis très surpris par ce fonctionnement. Mais comment font-ils ça ? Mais c'est vrai que ça me semble plus un patch pour combler une lacune de développement. Ce que l'on doit mocker doit-être... mockable. Et ça me semble un peu contre nature de remplacer à la volée du code qui est censé être figée, voire indépendant de tout contexte.
Tu sais ce qu'il font en arrière ? Injection de code IL ?