8
votes

MOQ une importation de Mef?

J'ai une classe A qui a ce qui suit: xxx

et un test pour tester ceci (DLL séparé - évidemment) xxx

Cela échoue comme tente d'appeler "myservice" me donne null. J'ai alors essayé: xxx

avec "myservice" déclaré comme: xxx

mais toujours pas de joie, suis-je toujours manque quelque chose - est-ce que cela est-ce même possible?

J'utilise SL3, MEF Aperçu 9 et MOQ.

Toute aide appréciée!

acclamations

chris


0 commentaires

3 Réponses :


2
votes

où vous avez ajouté [exportation] sur votre instance Imyservice, avez-vous réellement ajouté que dans le conteneur de composition? Sinon, cela ne participera pas à la composition. Pour ajouter un objet moqué au conteneur, procédez comme suit:

container.ComposeExportedValue(mock.Object); // type inference.


1 commentaires

Je n'ai pas besoin d'ajouter la mise en œuvre concrète à un conteneur pour le faire fonctionner. Mais je vois ton point. Où voyez-vous le conteneur?



7
votes

Votre classe devrait ressembler à ceci: xxx pré>

et votre test doit ressembler à ceci: p> xxx pré>

Le fait que vous utilisez mef ne devrait pas être important dans les tests unitaires. Le MEF entre en jeu uniquement lors de la câblage de nombreux composants ensemble, ce qui est exactement le contraire de ce qui se passe dans un test unitaire. Un test unitaire est par définition un test d'un composant isolément. P>

EDIT STRY>: Si vous préférez l'injection de la propriété, votre classe n'a pas besoin d'un constructeur et de l'organisation de l'organisation Votre test d'unité doit ressembler à ceci à la place: P>

    var myService = new Mock<IMyService>();
    var a = new A();
    a.MyService = myService.Object;


7 commentaires

Ok, mais pourquoi dois-je utiliser l'importateur de constructeur, la propriété fonctionne bien dans ma mise en œuvre réelle, vraisemblablement, il y a une route pour pouvoir se moquer de ces types d'importations?


@Chris: Bien que le MEF encourage l'injection de la propriété, je préfère l'injection de construction, car ce compilateur vous empêche de créer des objets avec des dépendances manquantes. Il vous permet également de faire les champs de dépendance réelle, de sorte que vous n'avez donc pas à penser à ce qui se passe si une dépendance est remplacée.


J'ai opté pour cette méthode, personnellement, j'aimerais toujours savoir si vous pouvez vous moquer de l'injection de la propriété, mais cela aide à résoudre le problème que j'avais. À votre santé.


Je pense que vous avez fait l'hypothèse que la propriété a un consecteur public. Ce qui, si vous injectionez, vous ne devez pas avoir besoin d'un setter public. Par exemple, j'ai un présentateur d'être injecté avec sa vue et vice-versa. Le présentateur encapsule la vue SO N'A PAS DE PUBLIC PUBLIC. Identique avec la vue, il est présenté est injecté et n'a pas de setter public.


@AIABRACT: Les points d'injection doivent être publics par définition. Sinon, vous dépendez de la magie du conteneur pour remplir les dépendances de votre composant. Et cela conduira ensuite à des problèmes lorsque vous devez réutiliser ce composant en dehors d'un conteneur (E.g. Tests unitaires) ou avec un conteneur différent qui ne supporte pas cela. Ces choses deviennent évidentes lorsque vous construisez une bibliothèque de composants réutilisable et vous n'avez pas de contrôle sur les différentes applications qui utilisent cette bibliothèque.


@Wimcoenen: Bien que je ne suis pas d'accord que points d'injection devrait être public par définition , je vois où il peut y avoir des difficultés si les points d'injection sont PAS PUBLIC. Dans le cas où j'ai un présentateur injecté avec une vue (et que la vue est injectée avec son présentateur), j'ai utilisé la réflexion pour "injecter" les objets simulés. Bien que c'était une contrariété mineure d'avoir cette exigence, ce que je n'ai pas à faire, c'est d'alimenter la composition pour chaque test et que mes vues restent encapsulées.


@WIMCOENEN: Après discussion avec un collègue, nous avons décidé de supprimer toute réflexion de mes tests d'unité tout en maintenant l'encapsulation des objets destinés. Merci pour les conseils!



1
votes

Vous ne devriez pas tirer de la MEF dans vos tests de l'unité. La composition est bien au-delà de la portée du test de l'unité, pas différente d'un conteneur de COI.

Installée, vous devez injecter des dépendances requises manuellement: p>

[TestClass]
public class ATest {
  Mock<IMyService> myService ;
  [TestInitialize]
  public void InitialiseClass() {
    myService = new Mock<IMyService>();
  }

  [TestMethod]
  public void DoWorkShouldCallDoIt {
    A a = new A();
    a.MyService = myService.Object;
    a.DoWork();
    myService.Verify(m=>m.DoIt(), Times.Once());
  }
}


0 commentaires