Maquette cadre vs MS Faux cadres

Question

Un peu confus sur les différences de cadres fictifs comme NMock vs la VS 2011 Faux Cadre. En passant par MSDN, ce que je comprends, c'est que des Fakes de vous permettre de vous moquer de votre dépendances comme RhinoMock ou NMock, mais l'approche est différente, les Faux génère du code pour réaliser cette fonctionnalité mais on se moque de cadre n'est pas. Donc ma compréhension correcte? Est Faux juste une autre Maquette cadre

Answer 1

Votre question était de savoir comment la MME Faux cadre est différent de NMock et il semble que les autres réponses ont résolu certains, mais voici quelques informations concernant la façon dont elles sont les mêmes et comment ils sont différents. NMock est également semblable à RhinoMocks et Moq, je suis donc de les regrouper avec NMock.

Il y a 3 grandes différences que je vois entre NMock/RhinoMocks/Moq) et MS Faux-Cadre:

• Le MS fakes framework utilise le code généré, à l'instar des Accesseurs dans les versions antérieures de Visual Studio, au lieu de types génériques. Lorsque vous souhaitez utiliser le faux cadre d'une dépendance, vous ajoutez de l'assembly qui contient la dépendance aux références du projet de test, puis cliquez-droit sur elle pour générer le test en double (stubs ou des cales). Ensuite, lorsque vous passez le test, vous êtes réellement en utilisant ces classes générées à la place. NMock utilise génériques pour accomplir la même chose (c'est à dire IStudentRepository studentRepository = mocks.NewMock<IStudentRepository>()). À mon avis, le MS Faux approche du cadre inhibe le code de la navigation et de refactoring de l'intérieur les épreuves depuis que vous travaillez à l'encontre d'une classe générée, pas votre interface réelle.

• Le MS faux-cadre de fournitures talons et les grains de beauté (cales), alors que NMock, RhinoMocks, et Moq fournir tous les talons et se moque. Je ne comprends vraiment pas MME la décision de ne pas inclure les objets fantaisie, et je suis personnellement pas fan de grains de beauté pour les raisons décrites ci-dessous.

• Avec le MS faux cadre, vous offre une alternative de mise en œuvre de la méthode que vous souhaitez stub. Au sein de ces autres implémentations, vous pouvez spécifier les valeurs de retour et le suivi des informations sur comment ou si la méthode a été appelée. Avec NMock, RhinoMocks et Moq, vous générez un objet fantaisie et ensuite utiliser cet objet pour spécifier écrasé les valeurs de retour ou le suivi d'interactions (si et comment ces méthodes ont été appelés). Je trouve le MS faux approche plus complexe et moins expressif.

Afin de clarifier la différence dans ce que les cadres assurer: NMock, RhinoMocks et Moq tous fournir deux types de test en double (les talons et se moque). Les fakes framework fournit talons et les grains de beauté (ils les appellent des cales), et, malheureusement, ne comprennent pas des simulacres. Afin de comprendre les différences et les similitudes entre les NMock et MS Faux, il est utile de comprendre ce que ces différents types de test, les chambres doubles sont:

Talons: Talons sont utilisés lorsque vous avez besoin de fournir des valeurs pour les propriétés ou méthodes sera demandé à votre test en double par la méthode à tester. Par exemple, quand ma méthode dans les appels de test de la DoesStudentExist() la méthode de la IStudentRepository test de double, je le veux retourner la valeur true.

L'idée de talons dans NMock et MS faux est le même, mais avec NMock vous ferait quelque chose comme ceci:

Stub.On(mockStudentRepository).Method("DoesStudentExist").Will(Return.Value(true));

Et avec MSFakes vous ne somethign comme ceci:

IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() // Generated by Fakes.
{
    DoesStudentExistInt32 = (studentId) => { return new Student(); }
};

Avis dans la MS Faux exemple, vous allez créer une toute nouvelle mise en œuvre de la DoesStudentExist méthode (à Noter qu'il est appelé DoesStudentExistInt32 parce que le faux cadre ajoute les types de données des paramètres de la méthode de noms lors de la génération des objets de talon, je pense que cela obscurcit la clarté des tests). Pour être honnête, la NMock mise en œuvre aussi qui me dérange, car il utilise une chaîne de caractères pour identifier le nom de la méthode. (Pardonnez-moi si j'ai mal compris comment NMock est destiné à être utilisé.) Cette approche vraiment inhibe la refactorisation et je recommande fortement d'RhinoMocks ou Moq sur NMock pour cette raison.

Se moque: on se moque sont utilisés pour vérifier l'interaction entre votre méthode en cours de test et de ses dépendances. Avec NMock, vous faites cela en définissant les attentes de similaire à ceci:

Expect.Once.On(mockStudentRepository).Method("Find").With(123);

C'est une autre raison pourquoi je préfère RhinoMocks et Moq sur NMock, NMock utilise l'ancienne attente de style alors que RhinoMocks et Moq à la fois le soutien de l'Arrangement/Act/Assert approche de l'endroit où vous vous préciser interactions attendues comme des assertions à la fin de l'essai comme ceci:

stubStudentRepository.AssertWasCalled( x => x.Find(123));

Encore une fois, notez que RhinoMocks utilise un lambda au lieu d'une chaîne afin d'identifier la méthode. Le ms faux-cadre ne fournit pas à se moque de tout. Cela signifie que dans votre écrasé implémentations (voir la description des talons au-dessus de), vous devez définir les variables que vous le vérifier par la suite ont été correctement définies. Qui ressemblerait à quelque chose comme ceci:

bool wasFindCalled = false;

IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() 
{
    DoesStudentExistInt32 = (studentId) => 
        { 
            wasFindCalled = true;
            return new Student(); 
        }
};

classUnderTest.MethodUnderTest();

Assert.IsTrue(wasFindCalled);

Je trouve cette approche un peu compliquée depuis que vous avez à suivre l'appel dans le talon et l'affirmer plus tard dans le test. Je trouve le NMock, et en particulier la RhinoMocks, des exemples à être plus expressif.

Moles (Cales): Pour être franc, je n'aime pas les grains de beauté, en raison de leur potentiel d'abus. L'une des choses que j'aime beaucoup sur les tests unitaires (et TDD en particulier), c'est que le test de votre code vous aide à comprendre où vous avez écrit de mauvais code. C'est parce que les tests de mal le code écrit est difficile. Ce n'est pas vrai lors de l'utilisation de grains de beauté parce que les taupes sont en fait conçues pour vous permettre de tester contre les dépendances qui ne sont pas d'injection, ou pour tester des méthodes privées. Ils fonctionnent de la même façon à talons, sauf que vous utilisez un ShimsContext comme ceci:

using (ShimsContext.Create())
{
    System.Fakes.ShimDateTime.NowGet = () => { return new DateTime(fixedYear, 1, 1); };
}

Mon inquiétude avec des cales, c'est que les gens vont commencer à voir comme "un moyen plus facile de test de l'unité", car il ne vous force pas à écrire le code comme vous le devez. Pour plus d'écrire sur ce concept, voir ce billet sur mon blog:

• http://blog.pluralsight.com/2012/05/22/solid-code-for-solid-reasons/

Pour plus d'informations sur certaines préoccupations liées à la faux cadres de prendre un coup d'oeil à ces postes:

• http://blog.pluralsight.com/2012/04/23/vs11-fakes-framework/

• http://blog.pluralsight.com/2012/04/25/vs11-fakes-framework-harmful-part-two/

Si vous êtes intéressés à en apprendre RhinoMocks voici un Pluralsight vidéo de formation (divulgation complète - j'ai écrit ce cours et obtenir le paiement de redevances pour les vues, mais je pense qu'elle s'applique à cette discussion, donc je suis, y compris ici):

• http://www.pluralsight.com/training/Courses/TableOfContents/rhinomock-fundamentals

Answer 2

Vous avez raison, mais il ya plus à l'histoire. Les choses les plus importantes à tirer de cette réponse sont:

1. Votre architecture doit en faire bon usage talons et l'injection de dépendance, plutôt que de s'appuyer sur la béquille de Faux et se moque de

2. Les faux et les simulacres sont utiles pour tester le code, vous ne devriez pas ou ne peut pas changer, tels que:

   • L'héritage du code qui n'utilisent pas (ou utilisation efficace) de talons
   • 3ème partie Api
   • Les ressources pour lesquelles vous n'avez pas le code source

Faux (connu sous le nom de "grains de beauté", en cours de développement) est en effet un moqueur cadre qui opère par le détour des appels. Au lieu de minutieusement la construction d'une maquette (oui, même en utilisant Moq est relativement pénible!), Faux utilisez simplement le code de production de l'objet déjà en place. Faux il suffit de ré-acheminer l'appel de la cible de production à l'épreuve délégué.

Les talons sont générés à partir des interfaces dans le projet cible. L'objet Stub est juste que-une implémentation de l'interface. L'avantage à l'utilisation de la souche type est que vous pouvez rapidement générer un talon sans encombrer votre projet de test avec beaucoup d'utilisation de paie, pour ne pas mentionner de perdre du temps à les créer. Bien sûr, vous devriez continuer à créer de béton talons, pour une utilisation dans de nombreux tests.

Efficacement la mise en œuvre de Faux et de Stub types prend un peu pour s'y habituer, mais vaut bien l'effort. Personnellement, j'ai sauvé semaines de temps de développement, grâce à l'utilisation de la Mole, de Faux, et le Talon types. J'espère que vous aurez autant de plaisir avec les technologies que j'ai!

Answer 3

Si je comprends bien, l'équipe Visual Studio voulait éviter la concurrence avec les différents maquette de bibliothèques disponibles pour .NET. MS se heurte souvent à des décisions difficiles comme ça. Ils sont barrés, si ils ne fournissent pas certaines fonctionnalités ("pourquoi ne pas MS de nous fournir une maquette de la bibliothèque; on se moque de sont une telle exigence commune?") et damné si ils font ("pourquoi est-ce que Microsoft agir de manière agressive et de la conduite de son naturel partisans du marché?") Très souvent, mais pas toujours, ils décident de se tenir le dos de la simple fourniture de leur propre alternative disponible et bien reçu des technologies. Cela semble être le cas ici.

La cale en fonction de Contrefaçons est vraiment, vraiment utile. Bien sûr, il y a des dangers. Il faut de la discipline pour vous assurer que vous utilisez uniquement ce cas de besoin. Cependant, il comble une grosse lacune. Mon principal reproche est qu'il n'est livré avec la dernière édition de VS 2012 et, par conséquent, ne sera disponible que pour un paragraphe de l' .NET développement de la communauté. Quel dommage.

Answer 4

Faux comprend deux types différents de "faux" de l'objet. Le premier, appelé un "stub", est essentiellement généré automatiquement factice dont le comportement par défaut peut (et normalement) être remplacée afin de le rendre plus intéressant de se moquer. Il ne, cependant, le manque certaines des caractéristiques que la plupart des moqueries des cadres de l'offre. Par exemple, si vous voulez vérifier qu'une méthode sur un talon instance a été invoquées, vous devez ajouter de la logique pour vous-même. Fondamentalement, si vous êtes à la création de vos propres objets fantaisie manuellement maintenant, talons serait probablement ressembler à une amélioration. Toutefois, si vous utilisez déjà un plus complet moqueur cadre, vous pourriez vous sentir comme il y a quelques pièces manquantes à partir des Faux talons.

L'autre catégorie d'objets offerts par des Faux, appelé une "cale", expose un mécanisme pour remplacer les comportements de dépendances qui ne l'ont pas été (ou ne peuvent pas) être découplé de manière adéquate pour la norme de remplacement par des simulacres. Autant que je sache, TypeMock est la seule des grandes infrastructures factices qui offre actuellement ce genre de fonctionnalité.

BTW, si vous avez essayé les Taupes avant, Faux est essentiellement la même chose, enfin fait son chemin hors de Microsoft Research et en un produit réel.

Answer 5

Concernant les Faux (Shim + Tampon) des objets, il a été bien défini ci-dessus, bien que je suppose que le dernier paragraphe dans le dernier commentaire résume la situation dans son ensemble assez bien.

Bien que beaucoup de personnes diront qu'Faux (Shim + Tampon) les objets sont bien actifs, dans certains tests unitaires cas, l'inconvénient est que, peu importe si vous êtes à l'aide de Visual Studio 2012 et Visual Studio 2013, ces options sont disponibles UNIQUEMENT avec la version Premium ou Ultimate versions. OIE, ce qui signifie que vous n'AUREZ PAS à fonctionner un de ces Faux (Shim + Tampon) sur toute version Pro.

Vous pouvez probablement voir le Faux (Shim + Tampon) option de menu sur les versions Pro, mais méfiez-vous, il y a quelques jolies de fortes chances que vous allez vous retrouver avec rien-absolument rien... Il ne génère aucune erreur de compilation de vous dire que quelque chose d'important est manquant, les options sont tout simplement pas, alors ne perdez pas votre temps...

C'est un facteur important à considérer dans l'équipe de développement, surtout si l'on est le seul à utiliser la version Ultimate alors que tout le monde utilise la version Pro... Moq sur l'autre main peut facilement être installé via Nuget peu importe la version de Visual Studio que vous utilisez. Je n'ai eu aucun problème à l'aide de Moq, la touche avec n'importe quel outil est de savoir à quoi ils servent et comment les utiliser correctement ;)