Mocking des classes scellées peut être assez pénible. Je privilégie actuellement un Modèle d'adaptateur pour gérer ça, mais quelque chose dans le fait de continuer me semble bizarre.
Alors, quelle est la meilleure façon de simuler des classes scellées ?
Les réponses de Java sont plus que bienvenues . En fait, je pense que la communauté Java s'occupe de ce problème depuis plus longtemps et qu'elle a beaucoup à offrir.
Mais voici quelques-unes des opinions de .NET :
Pour .NET, vous pouvez utiliser quelque chose comme TypeMock qui utilise l'API de profilage et vous permet d'accéder aux appels à presque tout.
+1. Utilisez les bons outils. Ne laissez pas les outils vous dicter comment faire les choses. Les API sont destinées aux personnes, pas aux outils - concevez-les comme telles. Utilisez les DI, les interfaces et le découplage total lorsque cela a du sens, et pas seulement parce que vous en avez besoin pour les outils de test.
Pavel - le problème est que la "bonne" façon de faire dans .NET vous conduit généralement sur le chemin de "l'utilisation de TypeMock pour tester". Suivre un chemin où il n'y a qu'un seul outil de test disponible ne semble pas génial non plus.
Je crois que Taupes de Microsoft Research, vous permet de le faire. Depuis la page sur les taupes :
Les taupes peuvent être utilisées pour détourner n'importe quelle méthode .NET y compris les méthodes non virtuelles/statiques. dans les types scellés.
UPDATE : il y a un nouveau cadre appelé "Fakes" dans la prochaine version VS 11 qui est conçu pour remplacer les taupes :
Le site Fakes Framework dans Visual Studio 11 est la prochaine génération de Moles & Stubs, et finira par le remplacer. Cependant, Fakes est différent de Moles, donc passer de Moles à Fakes nécessitera quelques modifications de votre code. Un guide pour cette migration sera disponible à une date ultérieure.
Exigences : Visual Studio 11 Ultimate, .NET 4.5
Ma règle générale est que les objets que je dois simuler doivent avoir une interface commune. Je pense que c'est une bonne conception et que cela rend les tests beaucoup plus faciles (et c'est généralement ce que vous obtenez si vous faites du TDD). Pour en savoir plus, consultez le blog Google Testing. dernier poste (Voir point 9).
Par ailleurs, j'ai travaillé principalement en Java au cours des quatre dernières années et je peux dire que je peux compter sur les doigts d'une main le nombre de fois où j'ai créé une classe finale (scellée). Une autre règle ici est que je dois toujours avoir une bonne raison de sceller une classe, plutôt que de la sceller par défaut.
Je dirais que vous devez avoir une bonne raison pas pour sceller une classe. Laisser une classe ouverte signifie que vous devez penser à la façon dont elle sera utilisée par les héritiers, ce qui ouvre la porte à une multitude de décisions concernant tout le code de la classe (virtualité, propriétés protégées ou variables membres privées, etc. dur pour concevoir correctement une classe pour l'héritage. Vous ne devriez pas être en mesure d'étendre une classe juste pour le plaisir de l'extension ; la dérivation devrait signifier quelque chose de spécifique au problème modélisé. Sinon, privilégiez plutôt la composition.
Bryan - alors comment faire pour simuler une classe scellée ? Je suis d'accord avec toi d'un point de vue théorique, mais si tu écris quelque chose qui dépend de ta classe scellée, alors tes tests dépendent aussi de la classe scellée.
@abyx : Malheureusement, ce n'est pas toujours le choix du développeur de savoir si une classe est scellée ou non. Prenez, par exemple, System.Web.HttpServerUtility dans ASP.NET...
Le problème avec TypeMock est qu'il excuse une mauvaise conception. Maintenant, je sais que c'est souvent de quelqu'un d'autre Il n'y a pas de mauvaise conception qu'il cache, mais le fait de l'autoriser dans votre processus de développement peut conduire très facilement à autoriser vos propres mauvaises conceptions.
Je pense que si vous devez utiliser un framework de mocking, vous devriez en utiliser un traditionnel (comme Moq) et créer une couche d'isolation autour de la chose non-mockable, et mocker la couche d'isolation à la place.
Le fait de ne pas coller des interfaces sur tout ce que vous voyez juste parce que vous en avez besoin à cause des déficiences de vos outils de test n'est pas une mauvaise conception. En fait, c'est plutôt le contraire - c'est sain d'esprit une conception qui porte sur le design, et non sur la conformité à vos outils. Je vous jure, parfois je pense que le TDD, tel qu'il est souvent pratiqué de manière dogmatique, devrait vraiment être appelé "conception pilotée par les outils". Voir aussi weblogs.asp.net/rosherove/archive/2008/01/17/
Pavel - avez-vous un autre outil que TypeMock qui peut fournir ce type de test ? Tester des classes construites avec des conceptions saines (par exemple, en utilisant des méthodes statiques, de nouveaux appels dans le code, en limitant les interfaces aux cas où plusieurs implémentations sont nécessaires, etc.
Je suis d'accord avec Brad. Créer un objet fantaisie implique que vous testez le comportement public de ce type. C'est-à-dire que vous dites spécifiquement : "J'ai besoin que l'API publique de cet objet se comporte d'une certaine manière". Ce comportement est indépendant de la manière dont ladite API est mise en œuvre. Cela signifie que vous avez une abstraction déjà définie (bien qu'implicite) qui doit se comporter d'une certaine manière. Dans un système de type statique, ceci doit être rendu explicite en créant un type abstrait.
J'évite presque toujours d'avoir des dépendances sur des classes externes au plus profond de mon code. Au lieu de cela, je préfère utiliser un adaptateur/pont pour leur parler. De cette façon, je m'occupe de ma sémantique, et la douleur de la traduction est isolée dans une classe.
Il est également plus facile de changer mes dépendances à long terme.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Ne vous moquez pas ! Utilisez plutôt la composition .