Est-il vrai que les frameworks moqueurs en général et que Rhino se moquent des interfaces et des classes qui ont une méthode virtuelle? Par exemple, puis-je me moquer de la classe simple suivante:Se moquer des classes d'interface
public class MyClass
{
void method1()
{
//some code goes here
}
}
Si la réponse est vraie, pourquoi une telle limitation existe-t-elle? Y a-t-il des solutions de rechange?
La limitation existe, car les cadres de simulation ne peuvent pas changer method1 sans qu'il soit virtuel ou une interface. C'est une limitation raisonnable, puisque les interfaces vous permettent de découpler vos dépendances et est un trait commun de bon code, IMO. Malheureusement, la plupart des frameworks .Net n'ont pas de méthodes ou interfaces virtuelles ... ce qui nécessite un wrapping moche pour créer des interfaces.
Si vous ne l'aimez pas vraiment, une option de cadre moqueur là-bas qui dépasse la limitation en accroissant le CLR avec un foo magique fou. Ce modèle est appelé TypeMock Isolator.
Je ne suis pas sûr de savoir comment vous vous moquez d'une classe qui n'a pas implémenté d'interface ou de méthodes virtuelles. Si du code attend une instance de MyClass et que vous lui transmettez une instance de MyDerivedMockClass, les membres MyClass ne seront pas accessibles aux membres MyDerivedMockClass, car ils ne sont pas des membres virtuels remplacés.
Typemock est votre meilleur pari.
Vous pouvez déviez les appels non-interface ou même statiques d'une manière similaire en utilisant MS taupes, bien que Moles est encore au stade expérimental et non un cadre complet moqueur: http://research.microsoft.com/en- us/projects/moles/ –
Brian - Je ne l'appellerais pas vraiment "crazy magic foo". C'est juste l'API Microsoft Profiling (http://msdn.microsoft.com/en-us/library/bb384382%28VS.90%29.aspx). :) – PatrickSteele
@Patrick Steele: assez bien. Il se sent juste comme foo magique foo :) –